Re: [SANDBOX][BeanUtils2] Unexpected behavior on Assertions.checkArgument(boolean, String, Object..)
Hi Benedikt!
don't get crazy with Assertions.* methods, they are just internal shortcuts!
OTOH I would focus the attention on public methods to invoke methods
via reflection, that would be really more useful.
Thanks for your efforts!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Jan 25, 2012 at 9:53 PM, Benedikt Ritter
b...@systemoutprintln.de wrote:
Hi,
I'm refactoring AssertionsTest to match the discussed best practices. I
wrote a test method for checkArgument(boolean Argument, String
errorTemplate, Object.. errorArgs):
@Test( expected = NullPointerException.class )
public void checkArgumentFalseStringNull()
{
checkArgument( false, ERROR_MSG, (Object[]) null );
}
The javadoc for checkArgument is:
@throws NullPointerException if the check fails and either {@code
errorMessageTemplate} or {@code errorMessageArgs} is null (don't let
this happen)
but when I execute the test, it fails because I'm getting an
IllegalStateException (instead of the expected NPE). Although this is
expected if false is passed in, it violates the contract described in the
javadoc. I'm not sure what to do now. I could either change the
implementation of checkArgument to throw the correct exception if errorArgs
is null or change the javadoc (remove the second part of the throws
declaration).
I would prefer the latter. But then one thing has to be paid attention to:
If we call checkArgument(false, ERROR_MSG) and ERROR_MSG contains any
placeholders (%s) and there are no errorArgs given, a
java.util.MissingArgumentFormatException will be thrown. So we would have to
deal with that.
Any thoughts?
All the best
Benedikt
PS: this also applies to checkState(boolean state, String errorTemplate,
Object... errorArgs)
-
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: [SANDBOX][BeanUtils2] Unexpected behavior on Assertions.checkArgument(boolean, String, Object..)
Am 26.01.2012 10:28, schrieb Simone Tripodi:
Hi Benedikt!
Hi Simo
don't get crazy with Assertions.* methods, they are just internal shortcuts!
okay, I'll just finish my general refactoring and ignore the very
special cases.
OTOH I would focus the attention on public methods to invoke methods
via reflection, that would be really more useful.
consider it done ;-)
There are two additional things that I have in mind:
- we should try to get some more structure into the project. For example
we could create packages for Bean*, Class* and Argument* Interfaces and
classes.
- it would be helpful, if you could give a very short overview over the
general architecture you have in mind. I have read through the source
code, but I'm not quite sure if I get the overall design idea. Also, if
there are implementations that you think are missing, please just let me
know what you have in mind, so I can create a patch.
Thanks for your efforts!
no problem, atm it is a lot of fun for me, and I'm learning a lot.
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Jan 25, 2012 at 9:53 PM, Benedikt Ritter
b...@systemoutprintln.de wrote:
Hi,
I'm refactoring AssertionsTest to match the discussed best practices. I
wrote a test method for checkArgument(boolean Argument, String
errorTemplate, Object.. errorArgs):
@Test( expected = NullPointerException.class )
public void checkArgumentFalseStringNull()
{
checkArgument( false, ERROR_MSG, (Object[]) null );
}
The javadoc for checkArgument is:
@throws NullPointerException if the check fails and either {@code
errorMessageTemplate} or {@code errorMessageArgs} is null (don't let
this happen)
but when I execute the test, it fails because I'm getting an
IllegalStateException (instead of the expected NPE). Although this is
expected if false is passed in, it violates the contract described in the
javadoc. I'm not sure what to do now. I could either change the
implementation of checkArgument to throw the correct exception if errorArgs
is null or change the javadoc (remove the second part of the throws
declaration).
I would prefer the latter. But then one thing has to be paid attention to:
If we call checkArgument(false, ERROR_MSG) and ERROR_MSG contains any
placeholders (%s) and there are no errorArgs given, a
java.util.MissingArgumentFormatException will be thrown. So we would have to
deal with that.
Any thoughts?
All the best
Benedikt
PS: this also applies to checkState(boolean state, String errorTemplate,
Object... errorArgs)
-
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: [SANDBOX][BeanUtils2] Unexpected behavior on Assertions.checkArgument(boolean, String, Object..)
Hi Benedikt,
- we should try to get some more structure into the project. For example we
could create packages for Bean*, Class* and Argument* Interfaces and
classes.
uhm, why you think it should be helpful? ATM only interfaces and
BeanUtils class are public - which are the smaller amount of code, and
the only APIs exposed to end-users. If we start layering and layering
at a certain point we have to make public some implementation, wich is
what I'm trying to avoid. Keep in miind that the purpose is making
BeanUtils expressive with fluent APIs, and not providing a set of
small tools to be reused.
- it would be helpful, if you could give a very short overview over the
general architecture you have in mind. I have read through the source code,
but I'm not quite sure if I get the overall design idea. Also, if there are
implementations that you think are missing, please just let me know what you
have in mind, so I can create a patch.
Have a look at current BeanUtils in the proper components, there are a
lot of features there that would be good to port - have a look at
DynaBean for example, I'll write another email on how I would like
those APIs would look alike.
Looking forward to hear more from you, all the best!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Jan 26, 2012 at 10:56 AM, Benedikt Ritter
b...@systemoutprintln.de wrote:
Am 26.01.2012 10:28, schrieb Simone Tripodi:
Hi Benedikt!
Hi Simo
don't get crazy with Assertions.* methods, they are just internal
shortcuts!
okay, I'll just finish my general refactoring and ignore the very special
cases.
OTOH I would focus the attention on public methods to invoke methods
via reflection, that would be really more useful.
consider it done ;-)
There are two additional things that I have in mind:
- we should try to get some more structure into the project. For example we
could create packages for Bean*, Class* and Argument* Interfaces and
classes.
- it would be helpful, if you could give a very short overview over the
general architecture you have in mind. I have read through the source code,
but I'm not quite sure if I get the overall design idea. Also, if there are
implementations that you think are missing, please just let me know what you
have in mind, so I can create a patch.
Thanks for your efforts!
no problem, atm it is a lot of fun for me, and I'm learning a lot.
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Wed, Jan 25, 2012 at 9:53 PM, Benedikt Ritter
b...@systemoutprintln.de wrote:
Hi,
I'm refactoring AssertionsTest to match the discussed best practices. I
wrote a test method for checkArgument(boolean Argument, String
errorTemplate, Object.. errorArgs):
@Test( expected = NullPointerException.class )
public void checkArgumentFalseStringNull()
{
checkArgument( false, ERROR_MSG, (Object[]) null );
}
The javadoc for checkArgument is:
@throws NullPointerException if the check fails and either {@code
errorMessageTemplate} or {@code errorMessageArgs} is null (don't let
this happen)
but when I execute the test, it fails because I'm getting an
IllegalStateException (instead of the expected NPE). Although this is
expected if false is passed in, it violates the contract described in the
javadoc. I'm not sure what to do now. I could either change the
implementation of checkArgument to throw the correct exception if
errorArgs
is null or change the javadoc (remove the second part of the throws
declaration).
I would prefer the latter. But then one thing has to be paid attention
to:
If we call checkArgument(false, ERROR_MSG) and ERROR_MSG contains any
placeholders (%s) and there are no errorArgs given, a
java.util.MissingArgumentFormatException will be thrown. So we would have
to
deal with that.
Any thoughts?
All the best
Benedikt
PS: this also applies to checkState(boolean state, String errorTemplate,
Object... errorArgs)
-
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
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Struts 2 Components
Last mail for today :-)
Today there is a discussion on going, Tapestry vs Struts (on
tapestry-users list). Of course people are convinced of Tapestry, and
actually it is a great framework with huge benefits. And it is pretty
modern. People now say (and not only there) Struts is a dinosaur.
Well, what I really liked on Wicket was the idea on components. I
think Wicket failed with it. But Tapestry did something similar, and
there it is working. Then there is Vaading, another great framework
supporting components.
I look at Struts. I see, we can use different presentation layers here
too. I am just not sure what other than jsp is really working. Are we
sure JavaTemplates work? We support Sitemesh2, which is pretty
outdated too.
These days people go to Components. I have thought a while about it...
shouldn't it be possible to use components in STruts too? We have DI
in place, which is a good backbone for that.
For example, look at this:
class MyAction {
@Inject
MyComponent blub; // Implements StrutsComponent
}
body
s2:component id=blub /
/body
Components might be able to return html. They can calculate. They can
be used with JSP. Looking at this:
http://tapestry.apache.org/component-reference.html
We can learn a bit from Tapestry here. Probably we are able to reuse
some of the components from them.
I begin to think a good frontend layer would bring benefits. Otherwise
it might happen S2 is more and more going into the direction service
layer, and for that it might not fit very well.
What do you think?
Cheers
Christian
--
http://www.grobmeier.de
https://www.timeandbill.de
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Struts 2 Components
Guten Morgen mate,
did you intend to send the message to Struts ML? ;)
Alles gute,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Jan 26, 2012 at 12:24 PM, Christian Grobmeier
grobme...@gmail.com wrote:
Last mail for today :-)
Today there is a discussion on going, Tapestry vs Struts (on
tapestry-users list). Of course people are convinced of Tapestry, and
actually it is a great framework with huge benefits. And it is pretty
modern. People now say (and not only there) Struts is a dinosaur.
Well, what I really liked on Wicket was the idea on components. I
think Wicket failed with it. But Tapestry did something similar, and
there it is working. Then there is Vaading, another great framework
supporting components.
I look at Struts. I see, we can use different presentation layers here
too. I am just not sure what other than jsp is really working. Are we
sure JavaTemplates work? We support Sitemesh2, which is pretty
outdated too.
These days people go to Components. I have thought a while about it...
shouldn't it be possible to use components in STruts too? We have DI
in place, which is a good backbone for that.
For example, look at this:
class MyAction {
@Inject
MyComponent blub; // Implements StrutsComponent
}
body
s2:component id=blub /
/body
Components might be able to return html. They can calculate. They can
be used with JSP. Looking at this:
http://tapestry.apache.org/component-reference.html
We can learn a bit from Tapestry here. Probably we are able to reuse
some of the components from them.
I begin to think a good frontend layer would bring benefits. Otherwise
it might happen S2 is more and more going into the direction service
layer, and for that it might not fit very well.
What do you think?
Cheers
Christian
--
http://www.grobmeier.de
https://www.timeandbill.de
-
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: Struts 2 Components
Oh yes, need more coffee!
Thanks for telling me
On Thu, Jan 26, 2012 at 12:32 PM, Simone Tripodi
simonetrip...@apache.org wrote:
Guten Morgen mate,
did you intend to send the message to Struts ML? ;)
Alles gute,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Jan 26, 2012 at 12:24 PM, Christian Grobmeier
grobme...@gmail.com wrote:
Last mail for today :-)
Today there is a discussion on going, Tapestry vs Struts (on
tapestry-users list). Of course people are convinced of Tapestry, and
actually it is a great framework with huge benefits. And it is pretty
modern. People now say (and not only there) Struts is a dinosaur.
Well, what I really liked on Wicket was the idea on components. I
think Wicket failed with it. But Tapestry did something similar, and
there it is working. Then there is Vaading, another great framework
supporting components.
I look at Struts. I see, we can use different presentation layers here
too. I am just not sure what other than jsp is really working. Are we
sure JavaTemplates work? We support Sitemesh2, which is pretty
outdated too.
These days people go to Components. I have thought a while about it...
shouldn't it be possible to use components in STruts too? We have DI
in place, which is a good backbone for that.
For example, look at this:
class MyAction {
@Inject
MyComponent blub; // Implements StrutsComponent
}
body
s2:component id=blub /
/body
Components might be able to return html. They can calculate. They can
be used with JSP. Looking at this:
http://tapestry.apache.org/component-reference.html
We can learn a bit from Tapestry here. Probably we are able to reuse
some of the components from them.
I begin to think a good frontend layer would bring benefits. Otherwise
it might happen S2 is more and more going into the direction service
layer, and for that it might not fit very well.
What do you think?
Cheers
Christian
--
http://www.grobmeier.de
https://www.timeandbill.de
-
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
--
http://www.grobmeier.de
https://www.timeandbill.de
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: Struts 2 Components
you're welcome!!!
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Jan 26, 2012 at 12:34 PM, Christian Grobmeier
grobme...@gmail.com wrote:
Oh yes, need more coffee!
Thanks for telling me
On Thu, Jan 26, 2012 at 12:32 PM, Simone Tripodi
simonetrip...@apache.org wrote:
Guten Morgen mate,
did you intend to send the message to Struts ML? ;)
Alles gute,
-Simo
http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/
On Thu, Jan 26, 2012 at 12:24 PM, Christian Grobmeier
grobme...@gmail.com wrote:
Last mail for today :-)
Today there is a discussion on going, Tapestry vs Struts (on
tapestry-users list). Of course people are convinced of Tapestry, and
actually it is a great framework with huge benefits. And it is pretty
modern. People now say (and not only there) Struts is a dinosaur.
Well, what I really liked on Wicket was the idea on components. I
think Wicket failed with it. But Tapestry did something similar, and
there it is working. Then there is Vaading, another great framework
supporting components.
I look at Struts. I see, we can use different presentation layers here
too. I am just not sure what other than jsp is really working. Are we
sure JavaTemplates work? We support Sitemesh2, which is pretty
outdated too.
These days people go to Components. I have thought a while about it...
shouldn't it be possible to use components in STruts too? We have DI
in place, which is a good backbone for that.
For example, look at this:
class MyAction {
@Inject
MyComponent blub; // Implements StrutsComponent
}
body
s2:component id=blub /
/body
Components might be able to return html. They can calculate. They can
be used with JSP. Looking at this:
http://tapestry.apache.org/component-reference.html
We can learn a bit from Tapestry here. Probably we are able to reuse
some of the components from them.
I begin to think a good frontend layer would bring benefits. Otherwise
it might happen S2 is more and more going into the direction service
layer, and for that it might not fit very well.
What do you think?
Cheers
Christian
--
http://www.grobmeier.de
https://www.timeandbill.de
-
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
--
http://www.grobmeier.de
https://www.timeandbill.de
-
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] Toward releasing 3.0 ?
Hi. It thus becomes urgent to tackle the remaining blocking issues. Can we please make a list of those, and of all practical matters that prevent the preparation of the release? MATH-621 (see also MATH-728) * Unit test coverage: at least 6 branches of the code are not explored. * Code complexity: - Variable state that is similar to having goto's - drop from one case to the next (no break) - explicit matrix computations * Code fragility: success or failure of some unit tests depends on the order of floating point operations (addition). * Support: no resource in the CM team to bring the code to a state where a Java developer can maintain it. I'm wary to release the code in that state. MATH-698 IIUC, CMAESOptimizer deals only with either no bounds or finite bounds. (e.g. look at method encode, lines 904-914). I don't have the knowledge about the algorithm in order to know how to modify that code so that it will behave correctly when only one of the bounds is infinite (a valid case allowed by the base class for optimizers with simple bounds: BaseAbstractMultivariateSimpleBoundsOptimizer). I would not want to release an API where simple bounds are dealt differently in CMAESOptimizer than in the supposedly common interface. MATH-726 This is really a small issue. But the discussion has stalled because of a long-term wish concerning a design convergence with the nabla project. I'd rather introduce the code now, in a form that is similar to the design of other packages (solvers, optimization, integration). I see no problem in changing that later, in the same way that there are suggestions to change other things (e.g. matrix interface, factories, ...). MATH-707 A few more changes to be done. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[SANDBOX][GRAPH] Eclipse vs. latest version
Hi all, I am experiencing a rather annoying issue with the latest version of commons-graph on Eclipse. Compiling with javac (maven, command line) it works fine, but the editor still complains: e.g. line 72 of the new FordFulkersonTestCase[1] gives a list of errors[2]. Now, I know from googling that Eclipse is not new to strange behavior, but I wanted to know if anyone on the ML has a nice answer, solution or workaround (other than standard answers like use another IDE), or at least experiences the same issue with the code. Thank you, Claudio --- [1] https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827view=markup [2] Multiple markers at this line - Bound mismatch: The generic method applyingFordFulkerson(OM) of type MaxFlowAlgorithmSelectorV,W,WE,G is not applicable for the arguments (IntegerWeight). The inferred type IntegerWeight is not a valid substitute for the bounded parameter OM extends OrderedMonoidObject - Type mismatch: cannot convert from Object to Integer - Bound mismatch: The generic method findMaxFlow(G) of type CommonsGraphV,E,G is not applicable for the arguments (DirectedMutableWeightedGraphBaseLabeledVertex,BaseLabeledWeightedEdgeInteger,Integer). The inferred type BaseLabeledWeightedEdgeInteger is not a valid substitute for the bounded parameter WE extends WeightedEdgeW -- Claudio Squarcella PhD student at Roma Tre University E-mail address: squar...@dia.uniroma3.it Phone: +39-06-57333215 Fax: +39-06-57333612 http://www.dia.uniroma3.it/~squarcel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
P.S. for completeness: Eclipse version: Indigo Service Release 1 Build id: 20110916-0149 OS: Mac OS X Lion Cheers, Claudio On 26/01/2012 15:30, Claudio Squarcella wrote: Hi all, I am experiencing a rather annoying issue with the latest version of commons-graph on Eclipse. Compiling with javac (maven, command line) it works fine, but the editor still complains: e.g. line 72 of the new FordFulkersonTestCase[1] gives a list of errors[2]. Now, I know from googling that Eclipse is not new to strange behavior, but I wanted to know if anyone on the ML has a nice answer, solution or workaround (other than standard answers like use another IDE), or at least experiences the same issue with the code. Thank you, Claudio --- [1] https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827view=markup [2] Multiple markers at this line - Bound mismatch: The generic method applyingFordFulkerson(OM) of type MaxFlowAlgorithmSelectorV,W,WE,G is not applicable for the arguments (IntegerWeight). The inferred type IntegerWeight is not a valid substitute for the bounded parameter OM extends OrderedMonoidObject - Type mismatch: cannot convert from Object to Integer - Bound mismatch: The generic method findMaxFlow(G) of type CommonsGraphV,E,G is not applicable for the arguments (DirectedMutableWeightedGraphBaseLabeledVertex,BaseLabeledWeightedEdgeInteger,Integer). The inferred type BaseLabeledWeightedEdgeInteger is not a valid substitute for the bounded parameter WE extends WeightedEdgeW -- Claudio Squarcella PhD student at Roma Tre University E-mail address: squar...@dia.uniroma3.it Phone: +39-06-57333215 Fax: +39-06-57333612 http://www.dia.uniroma3.it/~squarcel - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Hello. It thus becomes urgent to tackle the remaining blocking issues. Can we please make a list of those, and of all practical matters that prevent the preparation of the release? Thanks and best regards, Gilles As far as I'm concerned, I have been concentrating recently on MATH-677 and MATH-722. However, both issues are non-blocking, because I don't foresee any interface change now (regarding MATH-677, exposing the complex roots would just be a feature addition, as it is a private class right now). MATH-722 would merely be a bug correction. It was my impression that an identified bug is a blocking issue. Is it difficult to solve? If so, maybe that we can postpone it, and add a warning in the release notes (?). There is one thing I would like to reshape a little bit : that's the interface for IterativeLinearSolvers, which I found (after having used it) poorly designed. As this is blocking, maybe I should concentrate on this issue right now ? This, in my opinion, is not blocking. Maybe the design must be improved (as your own usage has shown already, it seems) but it could be done in 4.0. This design issue should not delay the release of 3.0. Of course, you can do whatever changes you think would be for the better. :-) Otherwise, I'm available for anything that would take us nearer to releasing 3.0 (how exciting! First release since I joined!). Same for me (first _major_ release). Those who know what must be done, could you please post here some pointers to a document that decribe the currently recommended and necessary steps for preparing a release? Thanks, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Hi Claudio!!! thanks for reporting, I have indeed the same issue - even if I thought was just an Eclipse bug! I honestly don't know how to fix the problem, I hope someone in the ML can provide a solution as well - same behavior met in IntelliJ!!! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: P.S. for completeness: Eclipse version: Indigo Service Release 1 Build id: 20110916-0149 OS: Mac OS X Lion Cheers, Claudio On 26/01/2012 15:30, Claudio Squarcella wrote: Hi all, I am experiencing a rather annoying issue with the latest version of commons-graph on Eclipse. Compiling with javac (maven, command line) it works fine, but the editor still complains: e.g. line 72 of the new FordFulkersonTestCase[1] gives a list of errors[2]. Now, I know from googling that Eclipse is not new to strange behavior, but I wanted to know if anyone on the ML has a nice answer, solution or workaround (other than standard answers like use another IDE), or at least experiences the same issue with the code. Thank you, Claudio --- [1] https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827view=markup [2] Multiple markers at this line - Bound mismatch: The generic method applyingFordFulkerson(OM) of type MaxFlowAlgorithmSelectorV,W,WE,G is not applicable for the arguments (IntegerWeight). The inferred type IntegerWeight is not a valid substitute for the bounded parameter OM extends OrderedMonoidObject - Type mismatch: cannot convert from Object to Integer - Bound mismatch: The generic method findMaxFlow(G) of type CommonsGraphV,E,G is not applicable for the arguments (DirectedMutableWeightedGraphBaseLabeledVertex,BaseLabeledWeightedEdgeInteger,Integer). The inferred type BaseLabeledWeightedEdgeInteger is not a valid substitute for the bounded parameter WE extends WeightedEdgeW -- Claudio Squarcella PhD student at Roma Tre University E-mail address: squar...@dia.uniroma3.it Phone: +39-06-57333215 Fax: +39-06-57333612 http://www.dia.uniroma3.it/~squarcel - 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] Toward releasing 3.0 ?
2012/1/26 Gilles Sadowski gil...@harfang.homelinux.org: Hello. It thus becomes urgent to tackle the remaining blocking issues. Can we please make a list of those, and of all practical matters that prevent the preparation of the release? Thanks and best regards, Gilles As far as I'm concerned, I have been concentrating recently on MATH-677 and MATH-722. However, both issues are non-blocking, because I don't foresee any interface change now (regarding MATH-677, exposing the complex roots would just be a feature addition, as it is a private class right now). MATH-722 would merely be a bug correction. It was my impression that an identified bug is a blocking issue. Is it difficult to solve? If so, maybe that we can postpone it, and add a warning in the release notes (?). Yes, you're right. So the quick answer is : the fix proposed by Juan is correct and *should* be implemented. However, I'm worried about accuracy of tanh(z) for large (but not too-large) values of the real part of z. I haven't had the time yet to investigate this specific point. There is one thing I would like to reshape a little bit : that's the interface for IterativeLinearSolvers, which I found (after having used it) poorly designed. As this is blocking, maybe I should concentrate on this issue right now ? This, in my opinion, is not blocking. Maybe the design must be improved (as your own usage has shown already, it seems) but it could be done in 4.0. This design issue should not delay the release of 3.0. Of course, you can do whatever changes you think would be for the better. :-) What I meant is: once it's in the wild, we cannot do anything until the next major release. I would like to add a couple of methods in the current interface (merely to be able to retrieve the current value of the residual, and the current iteration number). In fact I've been using these solvers recently and have lacked these methods. This can be done fairly quickly, but I need to think a little bit on the most appropriate way. Nothing major, but it would be nice if it was already in 3.0. Otherwise, I'm available for anything that would take us nearer to releasing 3.0 (how exciting! First release since I joined!). Same for me (first _major_ release). Those who know what must be done, could you please post here some pointers to a document that decribe the currently recommended and necessary steps for preparing a release? Thanks, Gilles Best regards, Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Toward releasing 3.0 ?
Hello, Hi. It thus becomes urgent to tackle the remaining blocking issues. Can we please make a list of those, and of all practical matters that prevent the preparation of the release? MATH-621 (see also MATH-728) * Unit test coverage: at least 6 branches of the code are not explored. * Code complexity: - Variable state that is similar to having goto's - drop from one case to the next (no break) - explicit matrix computations * Code fragility: success or failure of some unit tests depends on the order of floating point operations (addition). * Support: no resource in the CM team to bring the code to a state where a Java developer can maintain it. I'm wary to release the code in that state. The last point is indeed quite worrying. If we are planning for a release taking place briefly, I'm of no use, because digging into this would take me forever (even if it must be done in the end by one of us, I suppose). MATH-698 IIUC, CMAESOptimizer deals only with either no bounds or finite bounds. (e.g. look at method encode, lines 904-914). I don't have the knowledge about the algorithm in order to know how to modify that code so that it will behave correctly when only one of the bounds is infinite (a valid case allowed by the base class for optimizers with simple bounds: BaseAbstractMultivariateSimpleBoundsOptimizer). I would not want to release an API where simple bounds are dealt differently in CMAESOptimizer than in the supposedly common interface. MATH-726 This is really a small issue. But the discussion has stalled because of a long-term wish concerning a design convergence with the nabla project. I'd rather introduce the code now, in a form that is similar to the design of other packages (solvers, optimization, integration). I see no problem in changing that later, in the same way that there are suggestions to change other things (e.g. matrix interface, factories, ...). I agree. It's only after playing around with this new feature that we will be able to find its (potential) flaws. However, I do realize that not everyone may agree on this... MATH-707 A few more changes to be done. Regards, Gilles Sébastien - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Whew... I hope you guys love me. :P I decided to take a look just because I've had to play with Eclipse before on issues like this. What I typically find is that Eclipse has a sane reason for complaining where it does. This time I *really* thought Eclipse was wrong... but check this out: In the FordFulkersonTestCase, if you break this down statement by statement, what Eclipse is complaining about is findMaxFlow(graph);. Now, if you use Eclipse's 'Assign to local variable' quick assist, you find that it creates a variable of type: FromHeadBuilderBaseLabeledVertex, Object, BaseLabeledWeightedEdgeInteger, DirectedMutableWeightedGraphBaseLabeledVertex, BaseLabeledWeightedEdgeInteger, Integer Note that it has calculated the W type parameter to be Object. I am reasonably sure that the reason for this is that CommonsGraph.findMaxFlow's G type parameter is declared as G extends DirectedGraphV, WE. Thus the fact that our DirectedMutableWeightedGraph 'graph' has its W type parameter assigned as Integer is completely irrelevant as far as #findMaxFlow() is concerned. There is no way for the compiler to infer that #findMaxFlowW should be Integer in the context of the fully chained call. By contrast, simply changing Object to Integer in the signature of Eclipse's generated local variable gives the compiler enough to go on. I can only surmise that the Oracle (?) compiler may take the subsequent method calls into account when trying to infer type parameters from arguments, perhaps. So that's my diagnosis. How to cope with it while retaining fluency is another story. I'm not familiar enough with the domain or the API to be able to make any recommendation that would probably be terribly useful; however one thing that springs to mind is to take the CommonsGraph fluent APIs and move them to some typed interface, then have each level of the interface hierarchy define a public static final instance of this fluent interface that knows how to behave appropriately for that type...? Not sure if this would work properly in practice, but the best idea I'm likely to come up with. HTH, Matt On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi Claudio!!! thanks for reporting, I have indeed the same issue - even if I thought was just an Eclipse bug! I honestly don't know how to fix the problem, I hope someone in the ML can provide a solution as well - same behavior met in IntelliJ!!! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: P.S. for completeness: Eclipse version: Indigo Service Release 1 Build id: 20110916-0149 OS: Mac OS X Lion Cheers, Claudio On 26/01/2012 15:30, Claudio Squarcella wrote: Hi all, I am experiencing a rather annoying issue with the latest version of commons-graph on Eclipse. Compiling with javac (maven, command line) it works fine, but the editor still complains: e.g. line 72 of the new FordFulkersonTestCase[1] gives a list of errors[2]. Now, I know from googling that Eclipse is not new to strange behavior, but I wanted to know if anyone on the ML has a nice answer, solution or workaround (other than standard answers like use another IDE), or at least experiences the same issue with the code. Thank you, Claudio --- [1] https://svn.apache.org/viewvc/commons/sandbox/graph/trunk/src/test/java/org/apache/commons/graph/flow/FordFulkersonTestCase.java?revision=1235827view=markup [2] Multiple markers at this line - Bound mismatch: The generic method applyingFordFulkerson(OM) of type MaxFlowAlgorithmSelectorV,W,WE,G is not applicable for the arguments (IntegerWeight). The inferred type IntegerWeight is not a valid substitute for the bounded parameter OM extends OrderedMonoidObject - Type mismatch: cannot convert from Object to Integer - Bound mismatch: The generic method findMaxFlow(G) of type CommonsGraphV,E,G is not applicable for the arguments (DirectedMutableWeightedGraphBaseLabeledVertex,BaseLabeledWeightedEdgeInteger,Integer). The inferred type BaseLabeledWeightedEdgeInteger is not a valid substitute for the bounded parameter WE extends WeightedEdgeW -- Claudio Squarcella PhD student at Roma Tre University E-mail address: squar...@dia.uniroma3.it Phone: +39-06-57333215 Fax: +39-06-57333612 http://www.dia.uniroma3.it/~squarcel - 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
Re: [Math] Toward releasing 3.0 ?
On 26 January 2012 14:39, Gilles Sadowski gil...@harfang.homelinux.org wrote: Hello. It thus becomes urgent to tackle the remaining blocking issues. Can we please make a list of those, and of all practical matters that prevent the preparation of the release? Thanks and best regards, Gilles As far as I'm concerned, I have been concentrating recently on MATH-677 and MATH-722. However, both issues are non-blocking, because I don't foresee any interface change now (regarding MATH-677, exposing the complex roots would just be a feature addition, as it is a private class right now). MATH-722 would merely be a bug correction. It was my impression that an identified bug is a blocking issue. As usual - it depends. If the bug is a regression then it should probably block a release. But even then, if the reason for the regression was to fix a worse bug, then it may be OK to release. It also depends on the relative cost of fixing the bug before and after a release. If the bug is in a new API, it's generally going to be cheaper to fix before release rather than break compatibility later. Is it difficult to solve? If so, maybe that we can postpone it, and add a warning in the release notes (?). Adding a warning for known (major) bugs is a good idea. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
Terrific feedbacks - like always! - Matt, thanks a lot, very appreciated!!! We do - at least, I - love you! :D on. I can only surmise that the Oracle (?) compiler may take the subsequent method calls into account when trying to infer type parameters from arguments, perhaps. I am using the Apple's JDK: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Maven home: /Applications/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac however one thing that springs to mind is to take the CommonsGraph fluent APIs and move them to some typed interface, then have each level of the interface hierarchy define a public static final instance of this fluent interface that knows how to behave appropriately for that type...? Not sure if this would work properly in practice, but the best idea I'm likely to come up with. this is what I tried to do indeed, CommonsGraph#findMaxFlow returns an interface where generic types are inferred depending on the graph input. Thanks *a lot* for your kind help, always much more than appreciated!!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 5:08 PM, Matt Benson gudnabr...@gmail.com wrote: Whew... I hope you guys love me. :P I decided to take a look just because I've had to play with Eclipse before on issues like this. What I typically find is that Eclipse has a sane reason for complaining where it does. This time I *really* thought Eclipse was wrong... but check this out: In the FordFulkersonTestCase, if you break this down statement by statement, what Eclipse is complaining about is findMaxFlow(graph);. Now, if you use Eclipse's 'Assign to local variable' quick assist, you find that it creates a variable of type: FromHeadBuilderBaseLabeledVertex, Object, BaseLabeledWeightedEdgeInteger, DirectedMutableWeightedGraphBaseLabeledVertex, BaseLabeledWeightedEdgeInteger, Integer Note that it has calculated the W type parameter to be Object. I am reasonably sure that the reason for this is that CommonsGraph.findMaxFlow's G type parameter is declared as G extends DirectedGraphV, WE. Thus the fact that our DirectedMutableWeightedGraph 'graph' has its W type parameter assigned as Integer is completely irrelevant as far as #findMaxFlow() is concerned. There is no way for the compiler to infer that #findMaxFlowW should be Integer in the context of the fully chained call. By contrast, simply changing Object to Integer in the signature of Eclipse's generated local variable gives the compiler enough to go on. I can only surmise that the Oracle (?) compiler may take the subsequent method calls into account when trying to infer type parameters from arguments, perhaps. So that's my diagnosis. How to cope with it while retaining fluency is another story. I'm not familiar enough with the domain or the API to be able to make any recommendation that would probably be terribly useful; however one thing that springs to mind is to take the CommonsGraph fluent APIs and move them to some typed interface, then have each level of the interface hierarchy define a public static final instance of this fluent interface that knows how to behave appropriately for that type...? Not sure if this would work properly in practice, but the best idea I'm likely to come up with. HTH, Matt On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi Claudio!!! thanks for reporting, I have indeed the same issue - even if I thought was just an Eclipse bug! I honestly don't know how to fix the problem, I hope someone in the ML can provide a solution as well - same behavior met in IntelliJ!!! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: P.S. for completeness: Eclipse version: Indigo Service Release 1 Build id: 20110916-0149 OS: Mac OS X Lion Cheers, Claudio On 26/01/2012 15:30, Claudio Squarcella wrote: Hi all, I am experiencing a rather annoying issue with the latest version of commons-graph on Eclipse. Compiling with javac (maven, command line) it works fine, but the editor still complains: e.g. line 72 of the new FordFulkersonTestCase[1] gives a list of errors[2]. Now, I know from googling that Eclipse is not new to strange behavior, but I wanted to know if anyone on the ML has a nice answer, solution or workaround (other than standard answers like use another IDE), or at least experiences the same issue with the code. Thank you, Claudio --- [1]
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
FIXED Emanuele Lombardi, a former colleague of mine, simply did -public static V extends Vertex, W, WE extends WeightedEdgeW, G extends GraphV, WE SpanningTreeSourceSelectorV, W, WE, G minimumSpanningTree( G graph ) +public static V extends Vertex, WE extends WeightedEdgeW, W, G extends GraphV, WE SpanningTreeSourceSelectorV, W, WE, G minimumSpanningTree( G graph ) and it makes it working Isn't that cool? All the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 5:25 PM, Simone Tripodi simonetrip...@apache.org wrote: Terrific feedbacks - like always! - Matt, thanks a lot, very appreciated!!! We do - at least, I - love you! :D on. I can only surmise that the Oracle (?) compiler may take the subsequent method calls into account when trying to infer type parameters from arguments, perhaps. I am using the Apple's JDK: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Maven home: /Applications/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac however one thing that springs to mind is to take the CommonsGraph fluent APIs and move them to some typed interface, then have each level of the interface hierarchy define a public static final instance of this fluent interface that knows how to behave appropriately for that type...? Not sure if this would work properly in practice, but the best idea I'm likely to come up with. this is what I tried to do indeed, CommonsGraph#findMaxFlow returns an interface where generic types are inferred depending on the graph input. Thanks *a lot* for your kind help, always much more than appreciated!!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 5:08 PM, Matt Benson gudnabr...@gmail.com wrote: Whew... I hope you guys love me. :P I decided to take a look just because I've had to play with Eclipse before on issues like this. What I typically find is that Eclipse has a sane reason for complaining where it does. This time I *really* thought Eclipse was wrong... but check this out: In the FordFulkersonTestCase, if you break this down statement by statement, what Eclipse is complaining about is findMaxFlow(graph);. Now, if you use Eclipse's 'Assign to local variable' quick assist, you find that it creates a variable of type: FromHeadBuilderBaseLabeledVertex, Object, BaseLabeledWeightedEdgeInteger, DirectedMutableWeightedGraphBaseLabeledVertex, BaseLabeledWeightedEdgeInteger, Integer Note that it has calculated the W type parameter to be Object. I am reasonably sure that the reason for this is that CommonsGraph.findMaxFlow's G type parameter is declared as G extends DirectedGraphV, WE. Thus the fact that our DirectedMutableWeightedGraph 'graph' has its W type parameter assigned as Integer is completely irrelevant as far as #findMaxFlow() is concerned. There is no way for the compiler to infer that #findMaxFlowW should be Integer in the context of the fully chained call. By contrast, simply changing Object to Integer in the signature of Eclipse's generated local variable gives the compiler enough to go on. I can only surmise that the Oracle (?) compiler may take the subsequent method calls into account when trying to infer type parameters from arguments, perhaps. So that's my diagnosis. How to cope with it while retaining fluency is another story. I'm not familiar enough with the domain or the API to be able to make any recommendation that would probably be terribly useful; however one thing that springs to mind is to take the CommonsGraph fluent APIs and move them to some typed interface, then have each level of the interface hierarchy define a public static final instance of this fluent interface that knows how to behave appropriately for that type...? Not sure if this would work properly in practice, but the best idea I'm likely to come up with. HTH, Matt On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi Claudio!!! thanks for reporting, I have indeed the same issue - even if I thought was just an Eclipse bug! I honestly don't know how to fix the problem, I hope someone in the ML can provide a solution as well - same behavior met in IntelliJ!!! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 3:33 PM, Claudio Squarcella squar...@dia.uniroma3.it wrote: P.S. for completeness: Eclipse version: Indigo Service Release 1 Build id: 20110916-0149 OS: Mac
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi simonetrip...@apache.org wrote: FIXED Emanuele Lombardi, a former colleague of mine, simply did - public static V extends Vertex, W, WE extends WeightedEdgeW, G extends GraphV, WE SpanningTreeSourceSelectorV, W, WE, G minimumSpanningTree( G graph ) + public static V extends Vertex, WE extends WeightedEdgeW, W, G extends GraphV, WE SpanningTreeSourceSelectorV, W, WE, G minimumSpanningTree( G graph ) and it makes it working Isn't that cool? Hmm... doesn't seem to be working here on: Eclipse Platform Version: 3.7.1 Build id: M20110909-1335 Matt :| All the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 5:25 PM, Simone Tripodi simonetrip...@apache.org wrote: Terrific feedbacks - like always! - Matt, thanks a lot, very appreciated!!! We do - at least, I - love you! :D on. I can only surmise that the Oracle (?) compiler may take the subsequent method calls into account when trying to infer type parameters from arguments, perhaps. I am using the Apple's JDK: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Maven home: /Applications/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac however one thing that springs to mind is to take the CommonsGraph fluent APIs and move them to some typed interface, then have each level of the interface hierarchy define a public static final instance of this fluent interface that knows how to behave appropriately for that type...? Not sure if this would work properly in practice, but the best idea I'm likely to come up with. this is what I tried to do indeed, CommonsGraph#findMaxFlow returns an interface where generic types are inferred depending on the graph input. Thanks *a lot* for your kind help, always much more than appreciated!!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 5:08 PM, Matt Benson gudnabr...@gmail.com wrote: Whew... I hope you guys love me. :P I decided to take a look just because I've had to play with Eclipse before on issues like this. What I typically find is that Eclipse has a sane reason for complaining where it does. This time I *really* thought Eclipse was wrong... but check this out: In the FordFulkersonTestCase, if you break this down statement by statement, what Eclipse is complaining about is findMaxFlow(graph);. Now, if you use Eclipse's 'Assign to local variable' quick assist, you find that it creates a variable of type: FromHeadBuilderBaseLabeledVertex, Object, BaseLabeledWeightedEdgeInteger, DirectedMutableWeightedGraphBaseLabeledVertex, BaseLabeledWeightedEdgeInteger, Integer Note that it has calculated the W type parameter to be Object. I am reasonably sure that the reason for this is that CommonsGraph.findMaxFlow's G type parameter is declared as G extends DirectedGraphV, WE. Thus the fact that our DirectedMutableWeightedGraph 'graph' has its W type parameter assigned as Integer is completely irrelevant as far as #findMaxFlow() is concerned. There is no way for the compiler to infer that #findMaxFlowW should be Integer in the context of the fully chained call. By contrast, simply changing Object to Integer in the signature of Eclipse's generated local variable gives the compiler enough to go on. I can only surmise that the Oracle (?) compiler may take the subsequent method calls into account when trying to infer type parameters from arguments, perhaps. So that's my diagnosis. How to cope with it while retaining fluency is another story. I'm not familiar enough with the domain or the API to be able to make any recommendation that would probably be terribly useful; however one thing that springs to mind is to take the CommonsGraph fluent APIs and move them to some typed interface, then have each level of the interface hierarchy define a public static final instance of this fluent interface that knows how to behave appropriately for that type...? Not sure if this would work properly in practice, but the best idea I'm likely to come up with. HTH, Matt On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi Claudio!!! thanks for reporting, I have indeed the same issue - even if I thought was just an Eclipse bug! I honestly don't know how to fix the problem, I hope someone in the ML can provide a solution as well - same behavior met in IntelliJ!!! All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
ouch :( :( I suspect the trick just works on IntelliJ... ;( thanks for the feedbacks!!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 6:05 PM, Matt Benson gudnabr...@gmail.com wrote: On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi simonetrip...@apache.org wrote: FIXED Emanuele Lombardi, a former colleague of mine, simply did - public static V extends Vertex, W, WE extends WeightedEdgeW, G extends GraphV, WE SpanningTreeSourceSelectorV, W, WE, G minimumSpanningTree( G graph ) + public static V extends Vertex, WE extends WeightedEdgeW, W, G extends GraphV, WE SpanningTreeSourceSelectorV, W, WE, G minimumSpanningTree( G graph ) and it makes it working Isn't that cool? Hmm... doesn't seem to be working here on: Eclipse Platform Version: 3.7.1 Build id: M20110909-1335 Matt :| All the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 5:25 PM, Simone Tripodi simonetrip...@apache.org wrote: Terrific feedbacks - like always! - Matt, thanks a lot, very appreciated!!! We do - at least, I - love you! :D on. I can only surmise that the Oracle (?) compiler may take the subsequent method calls into account when trying to infer type parameters from arguments, perhaps. I am using the Apple's JDK: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Maven home: /Applications/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac however one thing that springs to mind is to take the CommonsGraph fluent APIs and move them to some typed interface, then have each level of the interface hierarchy define a public static final instance of this fluent interface that knows how to behave appropriately for that type...? Not sure if this would work properly in practice, but the best idea I'm likely to come up with. this is what I tried to do indeed, CommonsGraph#findMaxFlow returns an interface where generic types are inferred depending on the graph input. Thanks *a lot* for your kind help, always much more than appreciated!!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 5:08 PM, Matt Benson gudnabr...@gmail.com wrote: Whew... I hope you guys love me. :P I decided to take a look just because I've had to play with Eclipse before on issues like this. What I typically find is that Eclipse has a sane reason for complaining where it does. This time I *really* thought Eclipse was wrong... but check this out: In the FordFulkersonTestCase, if you break this down statement by statement, what Eclipse is complaining about is findMaxFlow(graph);. Now, if you use Eclipse's 'Assign to local variable' quick assist, you find that it creates a variable of type: FromHeadBuilderBaseLabeledVertex, Object, BaseLabeledWeightedEdgeInteger, DirectedMutableWeightedGraphBaseLabeledVertex, BaseLabeledWeightedEdgeInteger, Integer Note that it has calculated the W type parameter to be Object. I am reasonably sure that the reason for this is that CommonsGraph.findMaxFlow's G type parameter is declared as G extends DirectedGraphV, WE. Thus the fact that our DirectedMutableWeightedGraph 'graph' has its W type parameter assigned as Integer is completely irrelevant as far as #findMaxFlow() is concerned. There is no way for the compiler to infer that #findMaxFlowW should be Integer in the context of the fully chained call. By contrast, simply changing Object to Integer in the signature of Eclipse's generated local variable gives the compiler enough to go on. I can only surmise that the Oracle (?) compiler may take the subsequent method calls into account when trying to infer type parameters from arguments, perhaps. So that's my diagnosis. How to cope with it while retaining fluency is another story. I'm not familiar enough with the domain or the API to be able to make any recommendation that would probably be terribly useful; however one thing that springs to mind is to take the CommonsGraph fluent APIs and move them to some typed interface, then have each level of the interface hierarchy define a public static final instance of this fluent interface that knows how to behave appropriately for that type...? Not sure if this would work properly in practice, but the best idea I'm likely to come up with. HTH, Matt On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi Claudio!!! thanks for reporting, I have indeed the same issue - even if I
Re: [SANDBOX][GRAPH] Eclipse vs. latest version
On 26/01/2012 18:05, Matt Benson wrote: On Thu, Jan 26, 2012 at 11:01 AM, Simone Tripodi simonetrip...@apache.org wrote: FIXED Emanuele Lombardi, a former colleague of mine, simply did -public staticV extends Vertex, W, WE extends WeightedEdgeW, G extends GraphV, WE SpanningTreeSourceSelectorV, W, WE, G minimumSpanningTree( G graph ) +public staticV extends Vertex, WE extends WeightedEdgeW, W, G extends GraphV, WE SpanningTreeSourceSelectorV, W, WE, G minimumSpanningTree( G graph ) and it makes it working Isn't that cool? Hmm... doesn't seem to be working here on: Eclipse Platform Version: 3.7.1 Build id: M20110909-1335 same here. Maybe with another bit of tweaking like that (although that sounds a bit non-deterministic...) Claudio Matt :| All the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 5:25 PM, Simone Tripodi simonetrip...@apache.org wrote: Terrific feedbacks - like always! - Matt, thanks a lot, very appreciated!!! We do - at least, I - love you! :D on. I can only surmise that the Oracle (?) compiler may take the subsequent method calls into account when trying to infer type parameters from arguments, perhaps. I am using the Apple's JDK: Apache Maven 3.0.4 (r1232337; 2012-01-17 09:44:56+0100) Maven home: /Applications/apache-maven-3.0.4 Java version: 1.6.0_29, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac however one thing that springs to mind is to take the CommonsGraph fluent APIs and move them to some typed interface, then have each level of the interface hierarchy define a public static final instance of this fluent interface that knows how to behave appropriately for that type...? Not sure if this would work properly in practice, but the best idea I'm likely to come up with. this is what I tried to do indeed, CommonsGraph#findMaxFlow returns an interface where generic types are inferred depending on the graph input. Thanks *a lot* for your kind help, always much more than appreciated!!! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 26, 2012 at 5:08 PM, Matt Bensongudnabr...@gmail.com wrote: Whew... I hope you guys love me. :P I decided to take a look just because I've had to play with Eclipse before on issues like this. What I typically find is that Eclipse has a sane reason for complaining where it does. This time I *really* thought Eclipse was wrong... but check this out: In the FordFulkersonTestCase, if you break this down statement by statement, what Eclipse is complaining about is findMaxFlow(graph);. Now, if you use Eclipse's 'Assign to local variable' quick assist, you find that it creates a variable of type: FromHeadBuilderBaseLabeledVertex, Object, BaseLabeledWeightedEdgeInteger, DirectedMutableWeightedGraphBaseLabeledVertex, BaseLabeledWeightedEdgeInteger, Integer Note that it has calculated the W type parameter to be Object. I am reasonably sure that the reason for this is that CommonsGraph.findMaxFlow'sG type parameter is declared as G extends DirectedGraphV, WE. Thus the fact that our DirectedMutableWeightedGraph 'graph' has its W type parameter assigned as Integer is completely irrelevant as far as #findMaxFlow() is concerned. There is no way for the compiler to infer that #findMaxFlowW should be Integer in the context of the fully chained call. By contrast, simply changing Object to Integer in the signature of Eclipse's generated local variable gives the compiler enough to go on. I can only surmise that the Oracle (?) compiler may take the subsequent method calls into account when trying to infer type parameters from arguments, perhaps. So that's my diagnosis. How to cope with it while retaining fluency is another story. I'm not familiar enough with the domain or the API to be able to make any recommendation that would probably be terribly useful; however one thing that springs to mind is to take the CommonsGraph fluent APIs and move them to some typed interface, then have each level of the interface hierarchy define a public static final instance of this fluent interface that knows how to behave appropriately for that type...? Not sure if this would work properly in practice, but the best idea I'm likely to come up with. HTH, Matt On Thu, Jan 26, 2012 at 8:42 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi Claudio!!! thanks for reporting, I have indeed the same issue - even if I thought was just an Eclipse bug! I honestly don't know how to fix the problem, I hope someone in the ML can provide a solution as well - same behavior met in IntelliJ!!! All the best, -Simo
Re: [lang] What about Duration class? (org.apache.commons.lang.time)
On 1/26/2012 6:59 AM, Henri Yandell wrote: On Wed, Jan 25, 2012 at 2:14 PM, Christian Grobmeier grobme...@gmail.com wrote: On Wed, Jan 25, 2012 at 9:17 PM, Benedikt Ritter b...@systemoutprintln.de wrote: But i found only discussions about durationjoda-time dated 2004. (http://markmail.org/thread/733yqv5zwzsngj3j) Now i really need in Duration functionality (especially such as Duration.parse(String)). I heard about joda-time a while ago. My impression is, that the joda project is not that active anymore (please correct me, if I'm wrong). So I would vouch for additions to lang regarding durations. What I'm also really missing in lang.time is conversation of durations. For example: DurationUtils.convertToMinutes(long seconds). Joda Time is imho a great lib. Before a few weeks I replaced all the JDK stuff with Joda and it really saved my life. There was a release in July 2011 or so and my impression is more this lib is stable and does not need many releases. Actually I can't imagine a feature I miss in Joda at the moment. I don't understand the Commons point on this issue. - Commons Lang doesn't need in own implementation of this functionality and you suggest use joda-time? - Commons Lang needs in simplelightweight implementation of Duration? Also i cannot find correspond issue in jira (but Eric Crampton in 2004 wrote about Commons Lang task list that there is a need for DateRange/Duration classes). As you said, it is a while ago, since this was discussed. So let's review this topic again. What are your thoughts? Hen (who is mainly behind lang) and Gary already mentioned, they don't want to replicate Joda code into [lang]. I don't see any reasons why we should do that now. Instead I would prefer to mark the time package as deprecated and point users to joda. time does rely on jdk classes and as I have found out by own experience, it is dangerous to work with them. Long-term vision wise; my expectation is to drop our time package like a lead balloon as soon as Joda enters the JDK :) Just to clarify: Joda is not entering the JDK. JSR-310 has been proposed and might make it into the JDK, but JSR-310 is not Joda. http://jcp.org/en/jsr/detail?id=310 -Adrian - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang] What about Duration class? (org.apache.commons.lang.time)
Hi, Le 25/01/2012 21:17, Benedikt Ritter a écrit : Am 25.01.2012 21:02, schrieb Taras Ledkov: I'm very sorry if this problem has been solved in some way. No need to be sorry, as everybody can see, you did some research on this topic ;-) But i found only discussions about duration joda-time dated 2004. (http://markmail.org/thread/733yqv5zwzsngj3j) Now i really need in Duration functionality (especially such as Duration.parse(String)). If you want, there are several time-related classes in Orekit (see https://www.orekit.org/forge/projects/orekit/repository/revisions/master/show/src/main/java/org/orekit/time), including classes that are able to parse ISO-8601 format (see DateComponents and TimeComponents). Orekit is distributed under the terms of the Apache license, and I lead this project, so we can borrow some code from Orekit and push it into any Commons components. Orekit does handle duration, even taking into account non-regular time scales like UTC (i.e. it knows how to handle leap seconds introduction for time range that extend across a leap second). I can help on this if you want. Luc I heard about joda-time a while ago. My impression is, that the joda project is not that active anymore (please correct me, if I'm wrong). So I would vouch for additions to lang regarding durations. What I'm also really missing in lang.time is conversation of durations. For example: DurationUtils.convertToMinutes(long seconds). I don't understand the Commons point on this issue. - Commons Lang doesn't need in own implementation of this functionality and you suggest use joda-time? - Commons Lang needs in simple lightweight implementation of Duration? Also i cannot find correspond issue in jira (but Eric Crampton in 2004 wrote about Commons Lang task list that there is a need for DateRange/Duration classes). As you said, it is a while ago, since this was discussed. So let's review this topic again. What are your thoughts? Regards Benedikt - 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] Toward releasing 3.0 ?
Le 26/01/2012 15:39, Gilles Sadowski a écrit : Hello. It thus becomes urgent to tackle the remaining blocking issues. Can we please make a list of those, and of all practical matters that prevent the preparation of the release? Thanks and best regards, Gilles As far as I'm concerned, I have been concentrating recently on MATH-677 and MATH-722. However, both issues are non-blocking, because I don't foresee any interface change now (regarding MATH-677, exposing the complex roots would just be a feature addition, as it is a private class right now). MATH-722 would merely be a bug correction. It was my impression that an identified bug is a blocking issue. Is it difficult to solve? If so, maybe that we can postpone it, and add a warning in the release notes (?). There is one thing I would like to reshape a little bit : that's the interface for IterativeLinearSolvers, which I found (after having used it) poorly designed. As this is blocking, maybe I should concentrate on this issue right now ? This, in my opinion, is not blocking. Maybe the design must be improved (as your own usage has shown already, it seems) but it could be done in 4.0. This design issue should not delay the release of 3.0. +1 Of course, you can do whatever changes you think would be for the better. :-) Otherwise, I'm available for anything that would take us nearer to releasing 3.0 (how exciting! First release since I joined!). Same for me (first _major_ release). I agree we should release now, sorry for the very long delay. Those who know what must be done, could you please post here some pointers to a document that decribe the currently recommended and necessary steps for preparing a release? If you plane to use Nexus, here are some guidelines, mainly written by Sebb if I remember well: http://wiki.apache.org/commons/UsingNexus. Thanks, 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] Toward releasing 3.0 ?
Le 26/01/2012 15:52, Sébastien Brisard a écrit : Hello, Hi. It thus becomes urgent to tackle the remaining blocking issues. Can we please make a list of those, and of all practical matters that prevent the preparation of the release? MATH-621 (see also MATH-728) * Unit test coverage: at least 6 branches of the code are not explored. * Code complexity: - Variable state that is similar to having goto's - drop from one case to the next (no break) - explicit matrix computations * Code fragility: success or failure of some unit tests depends on the order of floating point operations (addition). * Support: no resource in the CM team to bring the code to a state where a Java developer can maintain it. I'm wary to release the code in that state. The last point is indeed quite worrying. If we are planning for a release taking place briefly, I'm of no use, because digging into this would take me forever (even if it must be done in the end by one of us, I suppose). As strange as it might seem, I would like to see this code part of 3.0 with a big experimental flag on it. People can use it at their own risk, but they can also help improve it. Luc MATH-698 IIUC, CMAESOptimizer deals only with either no bounds or finite bounds. (e.g. look at method encode, lines 904-914). I don't have the knowledge about the algorithm in order to know how to modify that code so that it will behave correctly when only one of the bounds is infinite (a valid case allowed by the base class for optimizers with simple bounds: BaseAbstractMultivariateSimpleBoundsOptimizer). I would not want to release an API where simple bounds are dealt differently in CMAESOptimizer than in the supposedly common interface. MATH-726 This is really a small issue. But the discussion has stalled because of a long-term wish concerning a design convergence with the nabla project. I'd rather introduce the code now, in a form that is similar to the design of other packages (solvers, optimization, integration). I see no problem in changing that later, in the same way that there are suggestions to change other things (e.g. matrix interface, factories, ...). I agree. It's only after playing around with this new feature that we will be able to find its (potential) flaws. However, I do realize that not everyone may agree on this... MATH-707 A few more changes to be done. Regards, Gilles Sébastien - 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 about Duration class? (org.apache.commons.lang.time)
On Jan 26, 2012, at 10:47, Adrian Crum adrian.c...@sandglass-software.com wrote: On 1/26/2012 6:59 AM, Henri Yandell wrote: On Wed, Jan 25, 2012 at 2:14 PM, Christian Grobmeier grobme...@gmail.com wrote: On Wed, Jan 25, 2012 at 9:17 PM, Benedikt Ritter b...@systemoutprintln.de wrote: But i found only discussions about durationjoda-time dated 2004. (http://markmail.org/thread/733yqv5zwzsngj3j) Now i really need in Duration functionality (especially such as Duration.parse(String)). I heard about joda-time a while ago. My impression is, that the joda project is not that active anymore (please correct me, if I'm wrong). So I would vouch for additions to lang regarding durations. What I'm also really missing in lang.time is conversation of durations. For example: DurationUtils.convertToMinutes(long seconds). Joda Time is imho a great lib. Before a few weeks I replaced all the JDK stuff with Joda and it really saved my life. There was a release in July 2011 or so and my impression is more this lib is stable and does not need many releases. Actually I can't imagine a feature I miss in Joda at the moment. I don't understand the Commons point on this issue. - Commons Lang doesn't need in own implementation of this functionality and you suggest use joda-time? - Commons Lang needs in simplelightweight implementation of Duration? Also i cannot find correspond issue in jira (but Eric Crampton in 2004 wrote about Commons Lang task list that there is a need for DateRange/Duration classes). As you said, it is a while ago, since this was discussed. So let's review this topic again. What are your thoughts? Hen (who is mainly behind lang) and Gary already mentioned, they don't want to replicate Joda code into [lang]. I don't see any reasons why we should do that now. Instead I would prefer to mark the time package as deprecated and point users to joda. time does rely on jdk classes and as I have found out by own experience, it is dangerous to work with them. Long-term vision wise; my expectation is to drop our time package like a lead balloon as soon as Joda enters the JDK :) Just to clarify: Joda is not entering the JDK. JSR-310 has been proposed and might make it into the JDK, but JSR-310 is not Joda. http://jcp.org/en/jsr/detail?id=310 Is this jsr dead? What's the next step? Gary -Adrian - 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 about Duration class? (org.apache.commons.lang.time)
On Jan 26, 2012, at 3:35 PM, Gary Gregory wrote: Just to clarify: Joda is not entering the JDK. JSR-310 has been proposed and might make it into the JDK, but JSR-310 is not Joda. http://jcp.org/en/jsr/detail?id=310 Is this jsr dead? What's the next step? See http://sourceforge.net/apps/mediawiki/threeten/index.php?title=ThreeTen. If you look at github you will notice that it is still being worked on. Ralph
[GUMP@vmgump]: Project commons-digester3 (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-digester3 has an issue affecting its community integration. This issue affects 2 projects, and has been outstanding for 46 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-digester3 : XML to Java Object Configuration - commons-digester3-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/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-digester3-*[0-9T].jar] identifier set to project name -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/digester/pom.xml -INFO- Failed to extract fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-digester3/gump_work/build_apache-commons_commons-digester3.html Work Name: build_apache-commons_commons-digester3 (Type: Build) Work ended in a state of : Failed Elapsed: 19 secs Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings /srv/gump/public/workspace/apache-commons/digester/gump_mvn_settings.xml package [Working Directory: /srv/gump/public/workspace/apache-commons/digester] M2_HOME: /opt/maven2 - /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[28,26] package com.sun.mirror.util does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[37,15] cannot find symbol symbol: class AnnotationProcessor implements AnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[40,18] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessor.java:[42,33] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessor /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[28,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[29,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[30,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[31,25] package com.sun.mirror.apt does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[32,33] package com.sun.mirror.declaration does not exist /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[41,15] cannot find symbol symbol: class AnnotationProcessorFactory implements AnnotationProcessorFactory /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[47,52] cannot find symbol symbol : class AnnotationTypeDeclaration location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessorFactory /srv/gump/public/workspace/apache-commons/digester/src/main/java/org/apache/commons/digester3/annotations/processor/DigesterAnnotationProcessorFactory.java:[48,48] cannot find symbol symbol : class AnnotationProcessorEnvironment location: class org.apache.commons.digester3.annotations.processor.DigesterAnnotationProcessorFactory
[GUMP@vmgump]: Project commons-exec-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-exec-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-exec-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-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/exec/gump_mvn_settings.xml] -DEBUG- (Apache Gump generated) Apache Maven Settings in: /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/exec/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/gump_work/build_apache-commons_commons-exec-test.html Work Name: build_apache-commons_commons-exec-test (Type: Build) Work ended in a state of : Failed Elapsed: 1 min 23 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/exec/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/exec] M2_HOME: /opt/maven2 - FOO.. gdal_translate HDF5:/home/kk/grass/data/4404.he5://HDFEOS/GRIDS/OMI_Column_Amount_O3/Data_Fields/ColumnAmountO3/home/kk/4.tif FOO.. PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.024 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.040 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.027 ms Process completed in 2006 millis; below is its output Process timed out and was killed by watchdog. org.apache.commons.exec.ExecuteException: Process exited with an error: 143 (Exit value: 143) Process completed in 2005 millis; below is its output Process timed out and was killed. Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Preparing to execute process - commandLine=[/bin/ls, /opt] Process spun off successfully - process=/bin/ls Executing [sh, -c, src/test/scripts/invoker.sh] invoker.sh -- going to start daemon process invoker.sh -- daemon process was started cd: 21: can't cd to ../../../target Process completed in 8026 millis; above is its output 0: process has terminated: false 1: process has terminated: false 2: process has terminated: false 3: process has terminated: false 4: process has terminated: false 5: process has terminated: false Tests run: 40, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 71.871 sec FAILURE! Results : Failed tests: testExec_60(org.apache.commons.exec.DefaultExecutorTest) Tests run: 95, Failures: 1, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/exec/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 minute 22 seconds [INFO] Finished at: Fri Jan 27 02:16:30 UTC 2012 [INFO] Final Memory: 25M/65M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-exec-test/atom.xml == Gump Tracking Only === Produced by Apache Gump(TM) version 2.3. Gump Run 1227012012, vmgump.apache.org:vmgump:1227012012 Gump E-mail Identifier (unique within run) #20. -- Apache Gump http://gump.apache.org/ [Instance: vmgump] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[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 365 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.004 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.018 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.142 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 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: Fri Jan 27 05:33:03 UTC 2012 [INFO] Final Memory: 24M/58M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom:
