Re: [lang] What's left for 3.0?
3 issues now, by punting the three non-blockers up to 3.1. Mostly it means that we need to decide what to do on LANG-624 and then get releasing. Hen On Sun, Jan 16, 2011 at 10:03 PM, Henri Yandell wrote: > And now down to 6 issues. > > 1 of them is a non-issue for release (JDK 1.7 has bugs); 1 is documentation. > > Of the other 4: > > LANG-462 - FastDateFormat supporting parse. Need to look at the > patches. Blocker for 3.0. > LANG-544 - ToStringStyle.registry thread issues. Need to consider > solution. Not a blocker for 3.0 imo. > LANG-624 - java.version vs java.specification.version. I'm +1 to > moving to specification.version. Blocker for 3.0. > LANG-288 - StrTokenizer needs to support access to the token > separators. It's an enhancement; while now is the time to implement > this, no one has. I'm thinking it should be punted to 3.1 and if the > solution involves incompatibility, it can wait for 4.0. > > So mostly we need to look at LANG-462, and resolve the debate on LANG-624. > > Hen > > On Sun, Jan 16, 2011 at 9:37 PM, Henri Yandell wrote: >> I took care of a few issues. 9 left to go; or they need to be declared >> as 'fix in 3.1 or 4.0'. I think at this point that anything that is a >> backwards incompatibility but not for 3.0 (i.e. the potential 4.0) >> should be resolved as 'wontfix'. The StrTokenizer issue jumps to mind. >> >> Also need to look for TODO statements in the code; I think I have a >> few in the translator stuff that I need to tidy up. >> >> Hen >> >> On Sat, Jan 15, 2011 at 10:25 AM, Henri Yandell wrote: >>> See JIRA :) >>> >>> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310481&fixfor=12311714&resolution=-1&sorter/field=priority&sorter/order=DESC >>> >>> On Fri, Jan 14, 2011 at 12:42 PM, Matt Benson wrote: See title. -Matt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] What's left for 3.0?
Hi Hen, Henri Yandell wrote: > 3 issues now, by punting the three non-blockers up to 3.1. > > Mostly it means that we need to decide what to do on LANG-624 and then > get releasing. In the light of LANG-577, I wondered if the mutable package is still necessary looking at the concurrent stuff of the JDK. I tried once to start a discussion about it (http://article.gmane.org/gmane.comp.jakarta.commons.devel/112282), but got no response. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] What's left for 3.0?
On 27 January 2011 08:45, Jörg Schaible wrote: > In the light of LANG-577, I wondered if the mutable package is still > necessary looking at the concurrent stuff of the JDK. I tried once to start > a discussion about it > (http://article.gmane.org/gmane.comp.jakarta.commons.devel/112282), but got > no response. The mutable classes cover a broader range of stuff than the JDK Atomic* classes. And are a useful element in their own right. Stephen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[lang] Android users wanted :)
Guys, in the shed of LANG-624, can somebody tell us, what the different Android versions return for the java.version and java.specification.version? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] last steps before releasing 2.2 ?
- "Phil Steitz" a écrit :
> On Wed, Jan 26, 2011 at 2:21 PM, Luc Maisonobe
> wrote:
> > There are only two issues left in Jira for 2.2.
> >
> > I think MATH-488 could be considered resolved as the class has been
> > deprecated as requested 5 days ago.
> >
> > Concerning MATH-487, I understood we are going to keep
> > ConvergenceException as a base class for a bunch of lower level
> > exceptions. Who volunteers for this task and on what time frame ?
> >
> I will create JIRA and post a patch with the new exceptions this
> weekend.
>
> > Apart from these Jira issues, Phil wanted to remove binary
> > incompatibilities. We said the incompatibilities in ODE could not
> be
> > removed as they are internal only and required to fix bugs. We did
> not
> > conclude on FunctionException/DerivativeException.
>
> You convinced me (twice actually, sorry :) that there is no immediate
> user impact due to FunctionEvaluationException changes. One thing
> that I did not mention before is that for UnivaritaRealFunction
> specifically, the new setup implies that *all*
> UnivariateRealFunctions
> are going to be user-defined functions. I am not sure that this is
> strictly true (aren't there some places where [math] code creates
> UnivariateRealFunctions?) nor is it IMO a good constraint to force.
This is a good point I overlooked. There are several implementations of
UnivariateRealFunction in [math], typically used in root solvers. As an
example, the following code comes from the EventState class in
o.a.c.m.ode.events package:
final UnivariateRealFunction f = new UnivariateRealFunction() {
public double value(final double t) throws MathUserException {
try {
interpolator.setInterpolatedTime(t);
return handler.g(t, interpolator.getInterpolatedState());
} catch (EventException e) {
throw new MathUserException(e);
}
}
};
This instance is used for root solving and there is a catch corresponding to
the throw
shown above. The catch clause is:
} catch (MathUserException mue) {
final Throwable cause = mue.getCause();
if ((cause != null) && (cause instanceof EventException)) {
throw (EventException) cause;
}
throw mue;
}
And in fact the if statement is always true so the underlying event exception
is recovered.
This code means that when the new exception is used internally, it use in fact
only
used as a wrapper and unwrapped on exit. So whatever the exception is, we adapt
this
code and from a user standpoint nothing changes.
I agree tagging this exception "User" seem strange here, but it could be
replaced by any
other unchecked exception. We simply use the user API internally just because
it is
available and it seemed simpler to comply to it.
> Is there a way that we can avoid the change to
> UnivariateRealFunction?
Avoiding this change means we keep a checked exception and hence it goes up
in solvers, integrators, optimizers ...
>
> Regarding DerivativeException do the changes also require no user
> code
> changes? Why do these changes have to be in 2.2? Also, ask the same
> question as above about DerivativeException: does the underlying
> function have to be a user-defined function?
In this case, yes it is only for user-defined objects, there are no internal
use of
this yet. the reasons for puttingit in 2.2 is the same as
FunctionEvaluationException,
it helps transition towards 3.0.
>
> The was still a
> > question about removing binary incompatibilities in the
> optimization
> > framework. What do we do about this ?
>
> I will revert the optimization breaks if no one beats me to it. It
> is
> clear what needs to be done from the svn diffs (look at for example,
> at the log of AbstractLeastSquaresOptimizer
> ). We just need to remember to reapply the
> FastMath (MATH-375) changes. I will have time to work on this this
> weekend.
Great. I will not have much time this week end.
best regards,
Luc
>
> Phil
> >
> > Luc
> >
> >
> -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-scxml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 50 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-scxml-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html Work Name: build_apache-commons_commons-scxml-test (Type: Build) Work ended in a state of : Failed Elapsed: 18 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/scxml] M2_HOME: /opt/maven2 - --- T E S T S --- Running org.apache.commons.scxml.invoke.InvokeTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.482 sec Running org.apache.commons.scxml.test.TestingTestSuite Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.scxml.env.EnvTestSuite Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.201 sec Running org.apache.commons.scxml.SCXMLTestSuite Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.878 sec <<< FAILURE! Running org.apache.commons.scxml.issues.IssuesTestSuite Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.395 sec Running org.apache.commons.scxml.model.ModelTestSuite Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.415 sec <<< FAILURE! Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.scxml.semantics.SemanticsTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.054 sec Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.scxml.io.IOTestSuite Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.442 sec Results : Failed tests: testNamespacePrefixedXPathsEL(org.apache.commons.scxml.NamespacePrefixedXPathsTest) testDatamodelSimultaneousJsp(org.apache.commons.scxml.model.DatamodelTest) Tests run: 228, Failures: 2, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 17 seconds [INFO] Finished at: Thu Jan 27 09:50:53 UTC 2011 [INFO] Final Memory: 41M/98M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 06000627012011, vmgump.apache.org:vmgump:06000627012011 Gump E-mail Identifier (unique wit
[GUMP@vmgump]: Project commons-jelly-tags-quartz (in module commons-jelly) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-jelly-tags-quartz has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 38 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-quartz : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-jelly-tags-quartz-27012011.jar] identifier set to project name -DEBUG- Dependency on logging-log4j-12 exists, no need to add for property maven.jar.log4j. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property maven.jar.commons-jexl. -DEBUG- (Apache Gump generated) Apache Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports -WARNING- No directory [/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports] -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/gump_work/build_commons-jelly_commons-jelly-tags-quartz.html Work Name: build_commons-jelly_commons-jelly-tags-quartz (Type: Build) Work ended in a state of : Failed Elapsed: 4 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz] - java:compile: [echo] Compiling to /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes [javac] Compiling 7 source files to /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:198: org.quartz.CronTrigger is abstract; cannot be instantiated [javac] CronTrigger trigger = new CronTrigger( getName(), [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:201: cannot find symbol [javac] symbol : method setCronExpression(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setCronExpression( getSpec() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:206: cannot find symbol [javac] symbol : method setJobName(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setJobName( getJobName() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:207: cannot find symbol [javac] symbol : method setJobGroup(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setJobGroup( getJobGroup() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:208: cannot find symbol [javac] symbol : method setStartTime(java.util.Date) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setStartTime( new Date() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:118: org.quartz.JobDetail is abstract; cannot be instantiated [javac] JobDetail detail = new JobDetail( getName(), [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:122: cannot find symbol [javac] symbol : method setDurability(boolean) [javac] location: interface org.quartz.JobDetail [javac] detail.setDurability( true ); [javac] ^ [javac] /srv
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 50 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 11 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.022 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.153 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 10 seconds [INFO] Finished at: Thu Jan 27 10:26:46 UTC 2011 [INFO] Final Memory: 39M/94M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.o
Re: [Math] Function (package "analysis.function")
> What functions are you talking about? http://en.wikipedia.org/wiki/Generalised_logistic_function http://en.wikipedia.org/wiki/Step_function http://en.wikipedia.org/wiki/Gaussian_function ... Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Refactoring of package "analysis.integration" (MATH-501)
Hi.
> > I need some clarifications before embarking into the clean-up of that
> > package.
> >
> > The "integrate" method of interface "UnivariateRealIntegrator" is defined
> > as:
> > double integrate(UnivariateRealFunction f, double min, double max)
> > throws ConvergenceException, MathUserException,
> > IllegalArgumentException;
> >
> > As a comparison, a "solve" methods from the solver interface:
> > double solve(int maxEval, FUNC f, double min, double max);
> >
> > (1) Is the notion of "iteration" for the integrator similar to the number of
> > evaluation for the solvers? In other words, shall we now pass the (minimal
> > and maximal) numbers of iterations as parameters of "integrate"?
> >
> I can't remember why we decided to move away from having the maximum
> number of iterations a property of the solver, [...]
In the case of solvers, we suppose that the comparison of the efficiency of
different solvers is based on the number of calls to the function to be
solved (if the function evaluation is relatively slower than the solver code
itself). The number of iterations is only an implementation detail of the
solver code.
> but the same concept
> does apply to integrators. So to be consistent, we should probably
> make that change.
Which concept?
Alternative 1:
Do we have to consider only the number of evaluations, thus that
for the integrators too, the number of iterations is an implementation
detail (i.e. not allowing the user to set it)? [Change of semantics (and
interface).]
Alternative 2:
Is the number of iterations still a user-defined property in the case of
integrators but it should be passed in the call to "integrate". [Change of
interface.]
Or did you mean yet something else?
>
> > (2) Should there also be a limit on the number of function evaluations?
> >
> I think that would be a good enhancement here and actually for the
> solvers as well. We need to think carefully though about the burden
> that this places on implementations.
As reminded above, changing from an iteration-based to an evaluation-based
criterion makes it possible to uniformly set a time limit when solving or
optimizing a function.
I started that thread because I'm not so sure that it is useful for
integrators.
In other words, is it a common pattern where one would say: "I want to
compute this integral in less than n evaluations of the function." ?
> > (3) We have here an occurrence of "ConvergenceException" whereas the
> > potential problems that can actually occur are that the number of iterations
> > is too low or too high.
> > I thus propose to use the existing "MaxCountExceededException" for "too many
> > iterations". Shall I create a "MinCountNotReachedException" for "too few
> > iterations"?
>
> Where do we throw on too few iterations? Generally that is not an
> issue. [...]
See the doc of "setMinimalIterationCount" in "UnivariateRealIntegrator".
> In any case, per my previous post on ConvergenceException, I
> see MaxIterationsExceeded as logically a subclass of
> ConvergenceException.
In reply to that post, I reminded that there exists a
"MaxCountExceededException" that is a sub-class of
"MathIllegalStateException".
"MaxCountExceededException" is thrown by the very low-level "Incrementor"
class, and so it cannot be a subclass of a high-level concept such
"ConvergenceException".
A possible way out of this dilemma could be that "ConvergenceException"
objects will wrap a "cause" exception. Hence we could have:
public class ConvergenceException extends MathRuntimeException {
private MathRuntimeException cause;
public ConvergenceException(MathRuntimeException cause) {
this.cause = cause;
}
// ...
}
and
public class MaxIterationExceededException extends ConvergenceException {
private final int max;
public MaxIterationExceededException(MaxCountExceededException cause) {
super(cause);
max = cause.getMax();
}
// ...
}
> Another logical alternative would be to define
> an enum characterizing the failed convergence in ConvergenceException
> as diverge to +inf, diverge to -inf, diverge to NaN, max iterations
> exceeded and add a property to ConvergenceException holding this
> value. I favor separating out the subclasses because they can then
> carry more information [...]
+1 for subclasses.
> such as, for the divergence subclasses, the
> iteration number where the out of range value occured and for the max
> iterations exceeded what the max is.
Indeed; cf. above for the "max" example.
> >
> > (4) Is it OK to pass accuracy parameters as arguments to the constructors
> > (as is done for the solvers)?
> >
> Yes, but I am wondering why this is different from the maxIterations.
> Why are the accuracy properties properties of the solver and max
> iterations a method parameter? To be consistent, we should probably
> move all the way to the procedure style and pass these parameters to
> the solve/integrate methods as well.
With this comes some subjectivity.
I tend
Re: release commons validator 1.4
Any update to the status? 2011/1/19 Niall Pemberton > On Wed, Jan 19, 2011 at 3:09 PM, Jacob Zwiers > wrote: > > I'll echo that. > > > > I had put a query to the user's list a last week asking a similar > question. > > > > I understand that the committers are working on JSR-303 and validator2 > releases. > > > > However, I suspect we're not the only ones looking to get get off > Jakarta-ORO sooner than later. > > > > Is there an interest among committers to push a 1.4 release? > > I will try to find some time to look at doing this. > > > If so, where do you see volunteer help being most useful? > > At this point I don't know. I need to review/remember the state > validator is currently in and come up with a TODO list for a 1.4 > release. > > Niall > > > jz > > > > > > -Original Message- > > From: David Karlsen [mailto:davidkarl...@gmail.com] > > Sent: Wednesday, January 19, 2011 9:59 AM > > To: dev@commons.apache.org > > Subject: release commons validator 1.4 > > > > Hi. > > > > We'd be very interested in > > > http://commons.apache.org/validator/apidocs/org/apache/commons/validator/routines/checkdigit/LuhnCheckDigit.html- > > could 1.4 be released? > > It's been quite a while since the last 1.3.1 relase > > > > -- > > -- > > David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- -- David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
Re: [Math] Refactoring of package "analysis.integration" (MATH-501)
On Thu, Jan 27, 2011 at 6:50 AM, Gilles Sadowski wrote: > Hi. > >> > I need some clarifications before embarking into the clean-up of that >> > package. >> > >> > The "integrate" method of interface "UnivariateRealIntegrator" is defined >> > as: >> > double integrate(UnivariateRealFunction f, double min, double max) >> > throws ConvergenceException, MathUserException, >> > IllegalArgumentException; >> > >> > As a comparison, a "solve" methods from the solver interface: >> > double solve(int maxEval, FUNC f, double min, double max); >> > >> > (1) Is the notion of "iteration" for the integrator similar to the number >> > of >> > evaluation for the solvers? In other words, shall we now pass the (minimal >> > and maximal) numbers of iterations as parameters of "integrate"? >> > >> I can't remember why we decided to move away from having the maximum >> number of iterations a property of the solver, [...] > > In the case of solvers, we suppose that the comparison of the efficiency of > different solvers is based on the number of calls to the function to be > solved (if the function evaluation is relatively slower than the solver code > itself). The number of iterations is only an implementation detail of the > solver code. > The maxIterations setting, like the absolute and relative accuracy settings, are things we want to be able to reuse across activations, but they are part of the configuration of the numerical problem - no different actually than the upper and lower bounds or even the function itself. The numerical problem is "find a root of the function within the designated interval in less than max iterations with stopping criteria defined by the accuracy settings." If you change any of these configuration settings you may get different results. They are all parameters of the numerical problem being solved. If, for example, you are working with a function that has many roots in the interval, changing accuracy for the solver may result in (an approximation to) a different root being returned. >> but the same concept >> does apply to integrators. So to be consistent, we should probably >> make that change. > > Which concept? The concept of iteration up to a configured maximum number of iterations and convergence defined by the iterates getting close. > Alternative 1: > Do we have to consider only the number of evaluations, thus that > for the integrators too, the number of iterations is an implementation > detail (i.e. not allowing the user to set it)? [Change of semantics (and > interface).] The user needs to be able to set the maximum number of iterations. Given a fixed algorithm, the number of iterations is a configuration parameter. It represents the maximum number of times that the main iteration loop in the algorithm can be executed. The nature of the algorithm is documented and is part of the contract, so this is a config parameter that makes sense to expose to the user and allow the user to set. It will in general be more meaningful and easier to understand from the numerical analysis standpoint than the number of function evaluations, which while also useful to be able to control is in general harder to relate to the numerical algorithm (this really depends on the algorithm and the exact relationship will be more prone to implementation-specific variation than the number of iterations, which should in general mean the same thing in different implementations of the same algorithm). > Alternative 2: > Is the number of iterations still a user-defined property in the case of > integrators but it should be passed in the call to "integrate". [Change of > interface.] > Or did you mean yet something else? > I meant that the user needs to be able to specify it. I think the real issue here is what we are talking about above and below on object properties vs. method parameters. >> >> > (2) Should there also be a limit on the number of function evaluations? >> > >> I think that would be a good enhancement here and actually for the >> solvers as well. We need to think carefully though about the burden >> that this places on implementations. > > As reminded above, changing from an iteration-based to an evaluation-based > criterion makes it possible to uniformly set a time limit when solving or > optimizing a function. > I started that thread because I'm not so sure that it is useful for > integrators. > In other words, is it a common pattern where one would say: "I want to > compute this integral in less than n evaluations of the function." ? > Not as common as setting max iterations, but it could be useful as an optional configuration setting. I would see it working as an *additional* requirement, not replacing maxIterations - i.e., we throw ConvergenceException when either one of these constraints is violated. I need to review all of the integratiors though to make sure this is tractable (tracking function evaluations) and end-user meaningful. >> > (3) We have here an occurrence o
Re: [Math] Function (package "analysis.function")
On Thu, Jan 27, 2011 at 5:48 AM, Gilles Sadowski wrote: >> What functions are you talking about? > > http://en.wikipedia.org/wiki/Generalised_logistic_function > http://en.wikipedia.org/wiki/Step_function > http://en.wikipedia.org/wiki/Gaussian_function > ... > OK. The third one may be pretty much already available via Erf in the special package, but I am OK adding it explicitly. What might make sense is to define a new top-level package, "function" or "functions" and make "special" a subpackage of that and either classify the new ones in some way or put them in a subpackage called something like "common". I don't think the ones you have above belong in special; but like those in special today, they may end up having wide use across other packages, hence the placement in a top-level functions package. Phil > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] last steps before releasing 2.2 ?
On Thu, Jan 27, 2011 at 4:04 AM, wrote:
>
> - "Phil Steitz" a écrit :
>
>> On Wed, Jan 26, 2011 at 2:21 PM, Luc Maisonobe
>> wrote:
>> > There are only two issues left in Jira for 2.2.
>> >
>> > I think MATH-488 could be considered resolved as the class has been
>> > deprecated as requested 5 days ago.
>> >
>> > Concerning MATH-487, I understood we are going to keep
>> > ConvergenceException as a base class for a bunch of lower level
>> > exceptions. Who volunteers for this task and on what time frame ?
>> >
>> I will create JIRA and post a patch with the new exceptions this
>> weekend.
>>
>> > Apart from these Jira issues, Phil wanted to remove binary
>> > incompatibilities. We said the incompatibilities in ODE could not
>> be
>> > removed as they are internal only and required to fix bugs. We did
>> not
>> > conclude on FunctionException/DerivativeException.
>>
>> You convinced me (twice actually, sorry :) that there is no immediate
>> user impact due to FunctionEvaluationException changes. One thing
>> that I did not mention before is that for UnivaritaRealFunction
>> specifically, the new setup implies that *all*
>> UnivariateRealFunctions
>> are going to be user-defined functions. I am not sure that this is
>> strictly true (aren't there some places where [math] code creates
>> UnivariateRealFunctions?) nor is it IMO a good constraint to force.
>
> This is a good point I overlooked. There are several implementations of
> UnivariateRealFunction in [math], typically used in root solvers. As an
> example, the following code comes from the EventState class in
> o.a.c.m.ode.events package:
>
> final UnivariateRealFunction f = new UnivariateRealFunction() {
> public double value(final double t) throws MathUserException {
> try {
> interpolator.setInterpolatedTime(t);
> return handler.g(t, interpolator.getInterpolatedState());
> } catch (EventException e) {
> throw new MathUserException(e);
> }
> }
> };
>
> This instance is used for root solving and there is a catch corresponding to
> the throw
> shown above. The catch clause is:
>
> } catch (MathUserException mue) {
> final Throwable cause = mue.getCause();
> if ((cause != null) && (cause instanceof EventException)) {
> throw (EventException) cause;
> }
> throw mue;
> }
>
> And in fact the if statement is always true so the underlying event exception
> is recovered.
>
> This code means that when the new exception is used internally, it use in
> fact only
> used as a wrapper and unwrapped on exit. So whatever the exception is, we
> adapt this
> code and from a user standpoint nothing changes.
>
> I agree tagging this exception "User" seem strange here, but it could be
> replaced by any
> other unchecked exception. We simply use the user API internally just because
> it is
> available and it seemed simpler to comply to it.
>
>> Is there a way that we can avoid the change to
>> UnivariateRealFunction?
>
> Avoiding this change means we keep a checked exception and hence it goes up
> in solvers, integrators, optimizers ...
>
OK. But now that we have detected an "aroma" around unilaterally
making UnivariateRealFunction throw Math*User*Exception, I wonder if
there is a way to introduce an unchecked parent that gets us out of
this. We may want to reserve the right to do this in 3.0, so the "head
start" in 2.2 might be a head start to nowhere, unless we find a way
to fix it in 2.2 (or you convince us that the current setup is an OK
long-term solution).
Phil
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
RE: [lang] What's left for 3.0?
> -Original Message- > From: Henri Yandell [mailto:flame...@gmail.com] > Sent: Thursday, January 27, 2011 03:04 > To: Commons Developers List; gudnabr...@gmail.com > Subject: Re: [lang] What's left for 3.0? > > 3 issues now, by punting the three non-blockers up to 3.1. > > Mostly it means that we need to decide what to do on LANG-624 and then > get releasing. > > Hen Getting close... :) I agree with the punting. Release early, release often. Gary > > On Sun, Jan 16, 2011 at 10:03 PM, Henri Yandell wrote: > > And now down to 6 issues. > > > > 1 of them is a non-issue for release (JDK 1.7 has bugs); 1 is > documentation. > > > > Of the other 4: > > > > LANG-462 - FastDateFormat supporting parse. Need to look at the > > patches. Blocker for 3.0. > > LANG-544 - ToStringStyle.registry thread issues. Need to consider > > solution. Not a blocker for 3.0 imo. > > LANG-624 - java.version vs java.specification.version. I'm +1 to > > moving to specification.version. Blocker for 3.0. > > LANG-288 - StrTokenizer needs to support access to the token > > separators. It's an enhancement; while now is the time to implement > > this, no one has. I'm thinking it should be punted to 3.1 and if the > > solution involves incompatibility, it can wait for 4.0. > > > > So mostly we need to look at LANG-462, and resolve the debate on LANG- > 624. > > > > Hen > > > > On Sun, Jan 16, 2011 at 9:37 PM, Henri Yandell > wrote: > >> I took care of a few issues. 9 left to go; or they need to be declared > >> as 'fix in 3.1 or 4.0'. I think at this point that anything that is a > >> backwards incompatibility but not for 3.0 (i.e. the potential 4.0) > >> should be resolved as 'wontfix'. The StrTokenizer issue jumps to mind. > >> > >> Also need to look for TODO statements in the code; I think I have a > >> few in the translator stuff that I need to tidy up. > >> > >> Hen > >> > >> On Sat, Jan 15, 2011 at 10:25 AM, Henri Yandell > wrote: > >>> See JIRA :) > >>> > >>> > https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=1 > 2310481&fixfor=12311714&resolution=- > 1&sorter/field=priority&sorter/order=DESC > >>> > >>> On Fri, Jan 14, 2011 at 12:42 PM, Matt Benson > wrote: > See title. > > -Matt > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > >>> > >> > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] last steps before releasing 2.2 ?
Phil, > OK. But now that we have detected an "aroma" around unilaterally > making UnivariateRealFunction throw Math*User*Exception, I wonder if > there is a way to introduce an unchecked parent that gets us out of > this. We may want to reserve the right to do this in 3.0, so the "head > start" in 2.2 might be a head start to nowhere, unless we find a way > to fix it in 2.2 (or you convince us that the current setup is an OK > long-term solution). I don't understand what you mean. "MathUserException" is unchecked so it has no consequence that it is in a "throws" clause. Or do you want to not remove FunctionEvaluationException from the "throws" clause (because it is not a backward-compatible change)? Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Function (package "analysis.function")
On Thu, Jan 27, 2011 at 08:13:32AM -0500, Phil Steitz wrote: > On Thu, Jan 27, 2011 at 5:48 AM, Gilles Sadowski > wrote: > >> What functions are you talking about? > > > > http://en.wikipedia.org/wiki/Generalised_logistic_function > > http://en.wikipedia.org/wiki/Step_function > > http://en.wikipedia.org/wiki/Gaussian_function > > ... > > > OK. The third one may be pretty much already available via Erf in the > special package, but I am OK adding it explicitly. > > What might make sense is to define a new top-level package, "function" > or "functions" and make "special" a subpackage of that and either > classify the new ones in some way or put them in a subpackage called > something like "common". I don't think the ones you have above belong > in special; but like those in special today, they may end up having > wide use across other packages, hence the placement in a top-level > functions package. I think that it would be a bit unnatural that the "function" package is at the top-level because it contains classes that implement "UnivariateRealFunction" or "BivariateRealFunction", and those are defined in "analysis". Or maybe you want to move the interface definitions to the "function" package? Although the functions in "special" are also functions, the implementations have nothing in common, e.g. those in "special" do not refer to the interfaces defined in "analysis". Of course, if you mean that we should refactor the classes in package "special"... It would imply to have one function object for each of the static functions currently defined in the classes of the package "special". I could open an issue so that we further discuss the options after 2.2 is released. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [codec] Large test data set!
> -Original Message- > From: Julius Davies [mailto:juliusdav...@gmail.com] > Sent: Wednesday, January 26, 2011 18:18 > To: Commons Developers List > Subject: Re: [codec] Large test data set! > > >> However, it will probably do no harm to ask at legal@. > > > > Do we actually have to distribute it? Maybe we can add is as zip to the > > Maven repo and use the dependency plugin to download and extract it on > the > > fly. > > > > - Jörg > > > Another option: ask the copyright holder to relicense to us under > the ASL 2.0. That often works! I asked, we'll see what he says. Gary > > > > -- > yours, > > Julius Davies > 250-592-2284 (Home) > > $ sudo apt-get install cowsay > $ echo "Moo." | cowsay | cowsay -n | cowsay -n > http://juliusdavies.ca/cowsay/ > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Function (package "analysis.function")
On Thu, Jan 27, 2011 at 9:42 AM, Gilles Sadowski wrote: > On Thu, Jan 27, 2011 at 08:13:32AM -0500, Phil Steitz wrote: >> On Thu, Jan 27, 2011 at 5:48 AM, Gilles Sadowski >> wrote: >> >> What functions are you talking about? >> > >> > http://en.wikipedia.org/wiki/Generalised_logistic_function >> > http://en.wikipedia.org/wiki/Step_function >> > http://en.wikipedia.org/wiki/Gaussian_function >> > ... >> > >> OK. The third one may be pretty much already available via Erf in the >> special package, but I am OK adding it explicitly. >> >> What might make sense is to define a new top-level package, "function" >> or "functions" and make "special" a subpackage of that and either >> classify the new ones in some way or put them in a subpackage called >> something like "common". I don't think the ones you have above belong >> in special; but like those in special today, they may end up having >> wide use across other packages, hence the placement in a top-level >> functions package. > > I think that it would be a bit unnatural that the "function" package is > at the top-level because it contains classes that implement > "UnivariateRealFunction" or "BivariateRealFunction", and those are defined > in "analysis". Or maybe you want to move the interface definitions to the > "function" package? I see your point. Could be it makes sense to move the interfaces, but your observation below on special functions makes me think that may not be best. > Although the functions in "special" are also functions, the implementations > have nothing in common, e.g. those in "special" do not refer to the > interfaces defined in "analysis". Another good point. I am not sure it is best to force fit in this case, though, because there are parameters and variants (regularlized gamma, etc) to consider and I think that code using the current special implementations is clearer than it would be if we force fit an abstract interface on top. > Of course, if you mean that we should refactor the classes in package > "special"... It would imply to have one function object for each of the > static functions currently defined in the classes of the package "special". > Yeah, seems unnecessary to me. > I could open an issue so that we further discuss the options after 2.2 > is released. Please do open an issue describing the new functions, why we need them, etc. and we can talk about where to put them. I am also open to talking about refactoring the special functions, but find them pretty convenient and straightforward to use as they are now. Phil > > > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] last steps before releasing 2.2 ?
On Thu, Jan 27, 2011 at 9:20 AM, Gilles Sadowski wrote: > Phil, > >> OK. But now that we have detected an "aroma" around unilaterally >> making UnivariateRealFunction throw Math*User*Exception, I wonder if >> there is a way to introduce an unchecked parent that gets us out of >> this. We may want to reserve the right to do this in 3.0, so the "head >> start" in 2.2 might be a head start to nowhere, unless we find a way >> to fix it in 2.2 (or you convince us that the current setup is an OK >> long-term solution). > > I don't understand what you mean. > "MathUserException" is unchecked so it has no consequence that it is in a > "throws" clause. > Or do you want to not remove FunctionEvaluationException from the "throws" > clause (because it is not a backward-compatible change)? > The "aroma" I was referring to is that MathUserException is not, strictly speaking a suitable replacement for FunctionEvaluationException. The intent as described in the javadoc for MathUserException is that it allows exceptions in user-defined functions to be propagated through [math] API layers (an excellent idea, IMO). The problem is that FunctionEvaluationException is broader - it could apply to non-user-defined functions, as in the interpolation code that Luc pointed out. Making it the exception thrown by UnivariateRealFunction#solve de facto limits the scope of UnivariateRealFunction to user-defined functions. The current 2_x code cleverly replaces FunctionEvaluationException but still allows user functions to throw it and user code to catch and handle it. The problem is that it replaces it uniformly within [math] with MathUserException. What might be better would be to replace MathUserException with something like FunctionEvaluationException (oops - that name is taken - need something else) and then have the current MathUserException be a subclass, reserved for user functions. Most internal signatures would then reference FunctionEvaluationException2 (just kidding about the name, need something else), but user functions would throw MathUserException. Phil > > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Large test data set!
Hi Julius, Julius Davies wrote: >>> However, it will probably do no harm to ask at legal@. >> >> Do we actually have to distribute it? Maybe we can add is as zip to the >> Maven repo and use the dependency plugin to download and extract it on >> the fly. >> >> - Jörg > > > Another option: ask the copyright holder to relicense to us under > the ASL 2.0. That often works! Why do you want to include it into our Subversion? If it's downloade automatically for the test like any other dependency, what's wrong with it? - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [codec] Large test data set!
> -Original Message- > From: Jörg Schaible [mailto:joerg.schai...@scalaris.com] > Sent: Thursday, January 27, 2011 12:21 > To: dev@commons.apache.org > Subject: Re: [codec] Large test data set! > > Hi Julius, > > Julius Davies wrote: > > >>> However, it will probably do no harm to ask at legal@. > >> > >> Do we actually have to distribute it? Maybe we can add is as zip to the > >> Maven repo and use the dependency plugin to download and extract it on > >> the fly. > >> > >> - Jörg > > > > > > Another option: ask the copyright holder to relicense to us under > > the ASL 2.0. That often works! > > Why do you want to include it into our Subversion? If it's downloade > automatically for the test like any other dependency, what's wrong with it? It's not in a Maven repository, it's in a Zip file on SourceForge. Gary > > - Jörg > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] last steps before releasing 2.2 ?
Le 27/01/2011 17:49, Phil Steitz a écrit : > On Thu, Jan 27, 2011 at 9:20 AM, Gilles Sadowski > wrote: >> Phil, >> >>> OK. But now that we have detected an "aroma" around unilaterally >>> making UnivariateRealFunction throw Math*User*Exception, I wonder if >>> there is a way to introduce an unchecked parent that gets us out of >>> this. We may want to reserve the right to do this in 3.0, so the "head >>> start" in 2.2 might be a head start to nowhere, unless we find a way >>> to fix it in 2.2 (or you convince us that the current setup is an OK >>> long-term solution). >> >> I don't understand what you mean. >> "MathUserException" is unchecked so it has no consequence that it is in a >> "throws" clause. >> Or do you want to not remove FunctionEvaluationException from the "throws" >> clause (because it is not a backward-compatible change)? >> > The "aroma" I was referring to is that MathUserException is not, > strictly speaking a suitable replacement for > FunctionEvaluationException. The intent as described in the javadoc > for MathUserException is that it allows exceptions in user-defined > functions to be propagated through [math] API layers (an excellent > idea, IMO). The problem is that FunctionEvaluationException is > broader - it could apply to non-user-defined functions, as in the > interpolation code that Luc pointed out. Making it the exception > thrown by UnivariateRealFunction#solve de facto limits the scope of > UnivariateRealFunction to user-defined functions. The current 2_x > code cleverly replaces FunctionEvaluationException but still allows > user functions to throw it and user code to catch and handle it. The > problem is that it replaces it uniformly within [math] with > MathUserException. What might be better would be to replace > MathUserException with something like FunctionEvaluationException > (oops - that name is taken - need something else) and then have the > current MathUserException be a subclass, reserved for user functions. > Most internal signatures would then reference > FunctionEvaluationException2 (just kidding about the name, need > something else), but user functions would throw MathUserException. This seems a good idea to me, and I don't have ideas for a name of the higher level exception. Luc > > Phil >> >> Gilles >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Large test data set!
On 27 January 2011 17:24, Gary Gregory wrote: >> -Original Message- >> From: Jörg Schaible [mailto:joerg.schai...@scalaris.com] >> Sent: Thursday, January 27, 2011 12:21 >> To: dev@commons.apache.org >> Subject: Re: [codec] Large test data set! >> >> Hi Julius, >> >> Julius Davies wrote: >> >> >>> However, it will probably do no harm to ask at legal@. >> >> >> >> Do we actually have to distribute it? Maybe we can add is as zip to the >> >> Maven repo and use the dependency plugin to download and extract it on >> >> the fly. >> >> >> >> - Jörg >> > >> > >> > Another option: ask the copyright holder to relicense to us under >> > the ASL 2.0. That often works! >> >> Why do you want to include it into our Subversion? If it's downloade >> automatically for the test like any other dependency, what's wrong with it? > > It's not in a Maven repository, it's in a Zip file on SourceForge. Still, it should be easy enough to add some code to fetch it if required. I've done similar in the past for JMeter in Ant, but it should still be possible in Maven. AIUI, the test that uses the data is an optiional one, so why clutter SVN and the test Jars? Worst-case, just provide instructions how to obtain the data. > Gary > >> >> - Jörg >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[CODEC] Base-n refactoring
I think I've now got the Base32 classes to a reasonable state. (More tests are surely needed). I decided to drop all the static encode/decode methods, as this simplifies the class considerably. Perhaps one are two are needed, but it might be best to release without them and add later if there is a big demand. The default buffer size is quite large (8192), so I added an overridable method to define it. Users would have to subclass Base32 to use it, but at least the option is there. I did not want to add yet more parameters to the ctors. If we ever decide to add an Options class then it could be added there. If the API looks OK, I'd like to rework the Base64 classes to use it. Thoughts? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [codec] Large test data set!
> -Original Message- > From: sebb [mailto:seb...@gmail.com] > Sent: Thursday, January 27, 2011 14:51 > To: Commons Developers List > Subject: Re: [codec] Large test data set! > > On 27 January 2011 17:24, Gary Gregory > wrote: > >> -Original Message- > >> From: Jörg Schaible [mailto:joerg.schai...@scalaris.com] > >> Sent: Thursday, January 27, 2011 12:21 > >> To: dev@commons.apache.org > >> Subject: Re: [codec] Large test data set! > >> > >> Hi Julius, > >> > >> Julius Davies wrote: > >> > >> >>> However, it will probably do no harm to ask at legal@. > >> >> > >> >> Do we actually have to distribute it? Maybe we can add is as zip to > the > >> >> Maven repo and use the dependency plugin to download and extract it > on > >> >> the fly. > >> >> > >> >> - Jörg > >> > > >> > > >> > Another option: ask the copyright holder to relicense to us under > >> > the ASL 2.0. That often works! The author has agreed to ASL 2 the files. > >> > >> Why do you want to include it into our Subversion? If it's downloade > >> automatically for the test like any other dependency, what's wrong with > it? > > > > It's not in a Maven repository, it's in a Zip file on SourceForge. > > Still, it should be easy enough to add some code to fetch it if required. > I've done similar in the past for JMeter in Ant, but it should still > be possible in Maven. > > AIUI, the test that uses the data is an optiional one, so why clutter > SVN and the test Jars? Uh? How do you define clutter? Based on size? Gary > > Worst-case, just provide instructions how to obtain the data. > > > Gary > > > >> > >> - Jörg > >> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [CODEC] Base-n refactoring
> -Original Message-
> From: sebb [mailto:seb...@gmail.com]
> Sent: Thursday, January 27, 2011 15:13
> To: Commons Developers List
> Subject: [CODEC] Base-n refactoring
>
> I think I've now got the Base32 classes to a reasonable state. (More
> tests are surely needed).
>
> I decided to drop all the static encode/decode methods, as this
> simplifies the class considerably.
> Perhaps one are two are needed, but it might be best to release
> without them and add later if there is a big demand.
>
> The default buffer size is quite large (8192), so I added an
> overridable method to define it.
> Users would have to subclass Base32 to use it, but at least the option is
> there.
> I did not want to add yet more parameters to the ctors.
> If we ever decide to add an Options class then it could be added there.
>
> If the API looks OK, I'd like to rework the Base64 classes to use it.
>
> Thoughts?
Nice work! Thank you.
WRT hasData(). We have:
if (!baseNCodec.hasData()) {
This is better IMO:
if (baseNCodec.isEmpty()) {
I would rename hasData to isEmpty and adjust (there is only call site.)
Gary
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
RE: [CODEC] Base-n refactoring
> -Original Message- > From: sebb [mailto:seb...@gmail.com] > Sent: Thursday, January 27, 2011 15:13 > To: Commons Developers List > Subject: [CODEC] Base-n refactoring > > I think I've now got the Base32 classes to a reasonable state. (More > tests are surely needed). > > I decided to drop all the static encode/decode methods, as this > simplifies the class considerably. > Perhaps one are two are needed, but it might be best to release > without them and add later if there is a big demand. > > The default buffer size is quite large (8192), so I added an > overridable method to define it. > Users would have to subclass Base32 to use it, but at least the option is > there. > I did not want to add yet more parameters to the ctors. > If we ever decide to add an Options class then it could be added there. > > If the API looks OK, I'd like to rework the Base64 classes to use it. > > Thoughts? - A couple of Checkstyle issue (see Maven reports) - Some CPD issues that refactoring Base64 to BaseNCodec will clearly address. - Base32 code coverage is MUCH better. Cool. - method avail(): is there a better name: getAvailableBytes()?availableCount()? available()? remainingBytes()? - It would be nice to make it easier to configure the buffer size without subclassing. If I wanted a configurable class, I'd subclass and add an ivar... I know I know, the final issue ;) and I agree more ctors is nasty. Looking good for refactoring. Gary > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [CODEC] Base-n refactoring
On 27 January 2011 21:03, Gary Gregory wrote: >> -Original Message- >> From: sebb [mailto:seb...@gmail.com] >> Sent: Thursday, January 27, 2011 15:13 >> To: Commons Developers List >> Subject: [CODEC] Base-n refactoring >> >> I think I've now got the Base32 classes to a reasonable state. (More >> tests are surely needed). >> >> I decided to drop all the static encode/decode methods, as this >> simplifies the class considerably. >> Perhaps one are two are needed, but it might be best to release >> without them and add later if there is a big demand. >> >> The default buffer size is quite large (8192), so I added an >> overridable method to define it. >> Users would have to subclass Base32 to use it, but at least the option is >> there. >> I did not want to add yet more parameters to the ctors. >> If we ever decide to add an Options class then it could be added there. >> >> If the API looks OK, I'd like to rework the Base64 classes to use it. >> >> Thoughts? > > - A couple of Checkstyle issue (see Maven reports) > > - Some CPD issues that refactoring Base64 to BaseNCodec will clearly address. > > - Base32 code coverage is MUCH better. Cool. Probably partly because I eliminated all the static methods... > - method avail(): is there a better name: > getAvailableBytes()?availableCount()? available()? remainingBytes()? Probably - this is the original method name. java.io.InputStream uses available(), which seems OK. > - It would be nice to make it easier to configure the buffer size without > subclassing. If I wanted a configurable class, I'd subclass and add an > ivar... I know I know, the final issue ;) and I agree more ctors is nasty. At least it's possible now... > Looking good for refactoring. > > Gary > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [codec] Large test data set!
Gary Gregory wrote: >> -Original Message- >> From: Jörg Schaible [mailto:joerg.schai...@scalaris.com] >> Sent: Thursday, January 27, 2011 12:21 >> To: dev@commons.apache.org >> Subject: Re: [codec] Large test data set! >> >> Hi Julius, >> >> Julius Davies wrote: >> >> >>> However, it will probably do no harm to ask at legal@. >> >> >> >> Do we actually have to distribute it? Maybe we can add is as zip to >> >> the Maven repo and use the dependency plugin to download and extract >> >> it on the fly. >> >> >> >> - Jörg >> > >> > >> > Another option: ask the copyright holder to relicense to us under >> > the ASL 2.0. That often works! >> >> Why do you want to include it into our Subversion? If it's downloade >> automatically for the test like any other dependency, what's wrong with >> it? > > It's not in a Maven repository, it's in a Zip file on SourceForge. ... and it is a defined process to put something into central. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [math] last steps before releasing 2.2 ?
On Thu, Jan 27, 2011 at 08:31:05PM +0100, Luc Maisonobe wrote:
> Le 27/01/2011 17:49, Phil Steitz a écrit :
> > On Thu, Jan 27, 2011 at 9:20 AM, Gilles Sadowski
> > wrote:
> >> Phil,
> >>
> >>> OK. But now that we have detected an "aroma" around unilaterally
> >>> making UnivariateRealFunction throw Math*User*Exception, I wonder if
> >>> there is a way to introduce an unchecked parent that gets us out of
> >>> this. We may want to reserve the right to do this in 3.0, so the "head
> >>> start" in 2.2 might be a head start to nowhere, unless we find a way
> >>> to fix it in 2.2 (or you convince us that the current setup is an OK
> >>> long-term solution).
> >>
> >> I don't understand what you mean.
> >> "MathUserException" is unchecked so it has no consequence that it is in a
> >> "throws" clause.
> >> Or do you want to not remove FunctionEvaluationException from the "throws"
> >> clause (because it is not a backward-compatible change)?
> >>
> > The "aroma" I was referring to is that MathUserException is not,
> > strictly speaking a suitable replacement for
> > FunctionEvaluationException. The intent as described in the javadoc
> > for MathUserException is that it allows exceptions in user-defined
> > functions to be propagated through [math] API layers (an excellent
> > idea, IMO).
I somewhat agreed on this point, because it doesn't hurt, although, as said
earlier, I really doubt that we can set a standard. [Anyway IMO it's fine
that users create whatever exception they like.]
> > The problem is that FunctionEvaluationException is
> > broader - it could apply to non-user-defined functions, as in the
> > interpolation code that Luc pointed out.
I mentioned that the "interpolate" method creates an object that implements
the "UnivariateRealFunction" interface.
Unless I'm missing something, the "problem" you mention does not exist. The
actual problem was the very _existence_ of "FunctionEvaluationException": A
class that was almost never actually instantiated within CM (and in the
places where it was, it was the wrong thing to do). [And the fact that is
was a chacked exception made things worse: try/catch all the way up for
something that never happens! That's why I argued that it be removed.]
Back to the issue of the interpolators: When an interpolator implementation
encounters a problem, it must throw a specific exception that represents
that problem; it might be e.g. an "OutOfRangeException" (because the user is
trying to extrapolate) but it doesn't mean that "OutOfRangeException" must
be a subclass of a "FunctionEvaluationException" or even a subclass of an
"InterpolationException" (because, as a problem description,
"OutOfRangeException" is unrelated to those). These supposedly high-level
exception don't bring any new information to CM; they are empty shells.
> > Making it the exception
> > thrown by UnivariateRealFunction#solve de facto limits the scope of
> > UnivariateRealFunction to user-defined functions.
I don't get this. What is UnivariateRealFunction#solve ?
Anyways, (guessing from the last part of the sentence)
"UnivariateRealFunction" is certainly not limited to user-defined functions.
Implementations (within CM and outside it) can throw *any* kind of unchecked
exception. [It's just that, as I had also pointed out, the documentation is
misleading for the unwary user (who might think that catching
"MathUserException" will prevent any blow-up).]
> > The current 2_x
> > code cleverly replaces FunctionEvaluationException but still allows
> > user functions to throw it and user code to catch and handle it. The
> > problem is that it replaces it uniformly within [math] with
> > MathUserException. What might be better would be to replace
> > MathUserException with something like FunctionEvaluationException
> > (oops - that name is taken - need something else) and then have the
> > current MathUserException be a subclass, reserved for user functions.
> > Most internal signatures would then reference
> > FunctionEvaluationException2 (just kidding about the name, need
> > something else), but user functions would throw MathUserException.
>
> This seems a good idea to me, and I don't have ideas for a name of the
> higher level exception.
No, no, no.
In "trunk", there are only 4 instances where a "MathUserException" is
actually instantiated. In 3 of them, it is used to wrap a checked exception;
before the release of 3.0, these exceptions will be replaced by new ones,
unchecked and specific. The last occurrence is
---
if (Double.isNaN(ret)) {
throw new
MathUserException(LocalizedFormats.CUMULATIVE_PROBABILITY_RETURNED_NAN, x, p);
}
---
In this case, it should be replaced either by a "NotFiniteNumberException"
or by something more elaborate like "IterateRangeException" (?) as proposed
by Phil.
Best,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commo
Re: [codec] Large test data set!
On Jan 27, 2011, at 17:43, "Jörg Schaible" wrote: > Gary Gregory wrote: > >>> -Original Message- >>> From: Jörg Schaible [mailto:joerg.schai...@scalaris.com] >>> Sent: Thursday, January 27, 2011 12:21 >>> To: dev@commons.apache.org >>> Subject: Re: [codec] Large test data set! >>> >>> Hi Julius, >>> >>> Julius Davies wrote: >>> >> However, it will probably do no harm to ask at legal@. > > Do we actually have to distribute it? Maybe we can add is as zip to > the Maven repo and use the dependency plugin to download and extract > it on the fly. > > - Jörg Another option: ask the copyright holder to relicense to us under the ASL 2.0. That often works! >>> >>> Why do you want to include it into our Subversion? If it's downloade >>> automatically for the test like any other dependency, what's wrong with >>> it? >> >> It's not in a Maven repository, it's in a Zip file on SourceForge. > > ... and it is a defined process to put something into central. Yes that's true and a good point. But how do you read a data file from java that works from the build and any IDE. That code would need to be able to resolve the right location in the local M2 repo. This must have happened before. Maybe there is a way to add the right dir to the classpath and get the file as a resource through a class loader. Gary > > - Jörg > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Large test data set!
Gary Gregory wrote: > On Jan 27, 2011, at 17:43, "Jörg Schaible" wrote: > >> Gary Gregory wrote: >> -Original Message- From: Jörg Schaible [mailto:joerg.schai...@scalaris.com] Sent: Thursday, January 27, 2011 12:21 To: dev@commons.apache.org Subject: Re: [codec] Large test data set! Hi Julius, Julius Davies wrote: >>> However, it will probably do no harm to ask at legal@. >> >> Do we actually have to distribute it? Maybe we can add is as zip to >> the Maven repo and use the dependency plugin to download and extract >> it on the fly. >> >> - Jörg > > > Another option: ask the copyright holder to relicense to us under > the ASL 2.0. That often works! Why do you want to include it into our Subversion? If it's downloade automatically for the test like any other dependency, what's wrong with it? >>> >>> It's not in a Maven repository, it's in a Zip file on SourceForge. >> >> ... and it is a defined process to put something into central. > > Yes that's true and a good point. But how do you read a data file from > java that works from the build and any IDE. That code would need to be > able to resolve the right location in the local M2 repo. This must have > happened before. Maybe there is a way to add the right dir to the > classpath and get the file as a resource through a class loader. ?!? You would use the dependency plugin in the generate-resources phase to extract the zip file into your local target directory where you then access the file(s) in your test. Quite a normal action with Maven. And regarding an IDE there's no difference from any other task that generates resources or additional source files. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [codec] Large test data set!
Hi Gary, Gary Gregory wrote: >> >> > Another option: ask the copyright holder to relicense to us under >> >> > the ASL 2.0. That often works! > > The author has agreed to ASL 2 the files. IANAL, but how does ASL 2 cope with *data*? The author has IMHO chosen well his license. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [codec] Large test data set!
Jörg Schaible wrote: > Gary Gregory wrote: > >> On Jan 27, 2011, at 17:43, "Jörg Schaible" wrote: >> >>> Gary Gregory wrote: >>> > -Original Message- > From: Jörg Schaible [mailto:joerg.schai...@scalaris.com] > Sent: Thursday, January 27, 2011 12:21 > To: dev@commons.apache.org > Subject: Re: [codec] Large test data set! > > Hi Julius, > > Julius Davies wrote: > However, it will probably do no harm to ask at legal@. >>> >>> Do we actually have to distribute it? Maybe we can add is as zip to >>> the Maven repo and use the dependency plugin to download and extract >>> it on the fly. >>> >>> - Jörg >> >> >> Another option: ask the copyright holder to relicense to us under >> the ASL 2.0. That often works! > > Why do you want to include it into our Subversion? If it's downloade > automatically for the test like any other dependency, what's wrong > with it? It's not in a Maven repository, it's in a Zip file on SourceForge. >>> >>> ... and it is a defined process to put something into central. >> >> Yes that's true and a good point. But how do you read a data file from >> java that works from the build and any IDE. That code would need to be >> able to resolve the right location in the local M2 repo. This must have >> happened before. Maybe there is a way to add the right dir to the >> classpath and get the file as a resource through a class loader. > > ?!? > > You would use the dependency plugin in the generate-resources phase to > extract the zip file into your local target directory where you then > access the file(s) in your test. Quite a normal action with Maven. > > And regarding an IDE there's no difference from any other task that > generates resources or additional source files. BTW: If you're unsure how to do this, I can give this a shot at the weekend. Just an offer. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-collections4 (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-collections4 has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 64 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-collections4 : Collections - commons-collections4-testframework : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-collections4/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/collections/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/collections/pom.xml -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-collections4/gump_work/build_apache-commons_commons-collections4.html Work Name: build_apache-commons_commons-collections4 (Type: Build) Work ended in a state of : Failed Elapsed: 16 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/collections/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/collections] M2_HOME: /opt/maven2 - required: org.apache.commons.collections.Closure[] found: org.apache.commons.collections.Closure[] [INFO] 8 errors [INFO] - [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchTransformer.java:[68,38] invalid inferred types for T; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Predicate[] found: org.apache.commons.collections.Predicate[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchTransformer.java:[69,40] invalid inferred types for I; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Transformer[] found: org.apache.commons.collections.Transformer[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/OnePredicate.java:[66,38] invalid inferred types for T; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Predicate[] found: org.apache.commons.collections.Predicate[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchClosure.java:[66,38] invalid inferred types for T; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Predicate[] found: org.apache.commons.collections.Predicate[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/SwitchClosure.java:[67,36] invalid inferred types for E; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Closure[] found: org.apache.commons.collections.Closure[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/ChainedTransformer.java:[56,40] invalid inferred types for I; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Transformer[] found: org.apache.commons.collections.Transformer[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/NonePredicate.java:[61,38] invalid inferred types for T; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Predicate[] found: org.apache.commons.collections.Predicate[] /srv/gump/public/workspace/apache-commons/collections/src/java/org/apache/commons/collections/functors/ChainedClosure.java:[53,36] invalid inferred types for E; actual arguments do not conforms to inferred formal arguments required: org.apache.commons.collections.Closure[] found: org.apache.commons.collections.Closure[] [INFO] [INFO] For more information, run Maven with the -e switch [INFO] -
