Re: OGNL as a part of Commons

[Jörg Schaible]

Stephen Colebourne wrote:

> Based on what I know of OGNL, it is/was reasonably well used. Trying
> to merge it into another project doesn't help those existing users.
> 
> The question is what are the author(s) of OGNL looking for? A home for
> maintainance? The Apache brand? To reinvigorate it? The latter fits
> with a merger into other projects. The former should make commons ask
> if it wants to become a home for maintainance mode (not necessarily a
> bad thing).
> 
> I'm certainly arguing against a straight push into BeanUtils or JEXL.

+1

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox

[Simone Tripodi]

Hi Rahul!!!
sure of course, I'll prepare a special section on the documentation to
see a Digester->Digester3 migration scenario, so that also users can
know pros and cons.
Thanks for your support!
have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Wed, Mar 2, 2011 at 12:59 AM, Rahul Akolkar  wrote:
> On Mon, Feb 28, 2011 at 8:35 AM, Simone Tripodi
>  wrote:
>> Good morning all guys,
>> in the last month I've invested my spare time on redesigning a new
>> potential version of the Digester component in Sandbox, according to
>> what I proposed time ago on dev ML[1].
>> The experiment is complete at 95%, is not of course a release but
>> there are enough tests/samples/docs to start playing with it.
>> I also sent an email to users ML[2] requesting for feedbacks,
>> unfortunately no one expressed his opinion yet, but I'll be patient at
>> least for the next 2-3 weeks before pushing a request again.
>>
>> I'd like to ask also your feedbacks and suggestions, in case you would
>> be interested in a potential promotion on Proper, or it should be
>> contributed somewhere else like extras, but I hope it will find a
>> place in commons.
>> As Rahul proposed, since there are APIs breakage, maybe it should be
>> taken in consideration as a new component, but at the same time as
>> Matt suggested, since it processes inputs in the same way, maybe is
>> just a major release.
>>
>> WDT? What are your thoughts about it?
> 
>
> Can we see a "before and after" i.e. show API usages on either when
> parsing the same sample?
>
> As an aside, I'd suggest we all start new threads for peripheral
> discussions i.e. not directly about future of digester (such as
> suppressing unchecked warnings, we don't want to fill this important
> thread with that :-).
>
> -Rahul
>
>
>> Sorry if it looks like a silly
>> question but I've never taken part of a sandbox promotion.
>> Looking forward to hear from you, have a nice day!
>> Simo
>>
>> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6
>> [2] http://markmail.org/message/qybp7ra3g5tpeayi
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.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 - 403] Never propagate a "NullPointerException" resulting from bad usage of the API

[Bill Barker]

-Original Message- 
From: Gilles Sadowski

Sent: Tuesday, March 01, 2011 3:12 PM
To: dev@commons.apache.org
Subject: Re: [Math - 403] Never propagate a "NullPointerException" resulting 
from bad usage of the API



Hi.

It's a debate that goes on. Josh Bloch in his Effective Java book says 
NPE

is perfectly acceptable for bad arguments. So it really depends on your
perspective what an NPE represents. I prefer Josh's opinion but only 
because

every single argument probably creates lots of branch-checking that kills
cpu pipelining.

> As far as this issue is concerned (for what i have understood) i 
> believe
> that one way to separate NULL(s) that occur from the A.P.I. from 
> NULL(s)
> coming from wrong usage of A.P.I. by a user is the assert technique... 
> I

> didn't know a lot about it but from what i have read it should be
> implemented only in the private methods of the A.P.I. Check this link 
> out:

> "
> http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html";.
> Another choice is to create a new class that would check all the 
> arguments

> of every function we are interested in (for example: public
> checkArguments(Object... args)) [If i have understood correctly the 
> purpose

> of this issue...]. Any suggestions would be more than welcomed!


NPE is the symptom of a bug.
Using "NullArgumentException" instead of the standard NPE so that the CM
exception hierarchy is singly rooted (the root being "MathRuntimeEception"
in the development version). An advantage is that it is easy to determine
whether an exception is generated by CM. A drawback is that it is
non-standard but this is mitigated by the fact that all other exceptions 
are

also non-standard (e.g. "MathIllegalArgumentException" instead of IAE).
One has to take into account that we settled on this choice because it 
makes

it somewhat easier to implement other requirements (namely the localization
of the error messages). It's a compromise (without the localization
requirement, I would have favoured the standard exceptions). And, apart 
from

avoiding code duplication, this choice has some "features" (which might be
construed as advantages or drawbacks, depending on the viewpoint)...

I'm not sure of what you mean by "branch-checking", but I don't think that
checking for null makes the problem bigger than it would be otherwise, 
since

CM already checks for many things.

In the end, I'm really not sure what is the best approach for this
particular case. Personally, I'd be happy that the CM code never checks for
null and let the JVM throw NPE. This would hugely simplify the CM code,
albeit at the cost of detecting bad usage a little later. IMHO, it is not a
big deal because the bug is that an object is missing somewhere up the call
stack, and it should be corrected there...



I'm in favor of just letting the JVM throw NPE.  Since there is no message 
in this case, there is nothing to localize.  Using a class to check 
arguments is too much work, since the (localized) message "Something was 
null" is less than helpful.  And assert will be turned off in any reasonably 
configured production server so makes the code less readable and adds very 
little value.  If the null happens because of code in CM (as opposed to user 
error), then we'll get a Jira issue, fix it, and add a unit test.  If it is 
user error, then the stack trace of the NPE will tell the developer what was 
wrong in at least 95% of the cases.





Of course, this would mean that MATH-403 should be dropped, the
"NullArgumentException" class removed, and the policy changed to: "Never
check for null references".


Best,
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: [discuss][Digester] The future of Digester an the Digester3 in sandbox

[Rahul Akolkar]

On Mon, Feb 28, 2011 at 8:35 AM, Simone Tripodi
 wrote:
> Good morning all guys,
> in the last month I've invested my spare time on redesigning a new
> potential version of the Digester component in Sandbox, according to
> what I proposed time ago on dev ML[1].
> The experiment is complete at 95%, is not of course a release but
> there are enough tests/samples/docs to start playing with it.
> I also sent an email to users ML[2] requesting for feedbacks,
> unfortunately no one expressed his opinion yet, but I'll be patient at
> least for the next 2-3 weeks before pushing a request again.
>
> I'd like to ask also your feedbacks and suggestions, in case you would
> be interested in a potential promotion on Proper, or it should be
> contributed somewhere else like extras, but I hope it will find a
> place in commons.
> As Rahul proposed, since there are APIs breakage, maybe it should be
> taken in consideration as a new component, but at the same time as
> Matt suggested, since it processes inputs in the same way, maybe is
> just a major release.
>
> WDT? What are your thoughts about it?


Can we see a "before and after" i.e. show API usages on either when
parsing the same sample?

As an aside, I'd suggest we all start new threads for peripheral
discussions i.e. not directly about future of digester (such as
suppressing unchecked warnings, we don't want to fill this important
thread with that :-).

-Rahul


> Sorry if it looks like a silly
> question but I've never taken part of a sandbox promotion.
> Looking forward to hear from you, have a nice day!
> Simo
>
> [1] http://markmail.org/message/5ry2lmfkpxkrqwh6
> [2] http://markmail.org/message/qybp7ra3g5tpeayi
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [scxml] semantics of nested history in parallel state

[Rahul Akolkar]

On Tue, Mar 1, 2011 at 6:57 PM, Jacob Beard  wrote:
> Please keep an eye on the www-voice thread. I think there may still be
> problems with the current step algorithm, and I'm drafting a reply to
> elaborate on this.
>


Sure.

-Rahul


> Thanks,
>
> Jake
>
> On Tue, Mar 1, 2011 at 6:50 PM, Rahul Akolkar  wrote:
>> On Sun, Feb 27, 2011 at 11:51 AM, Jacob Beard  wrote:
>>> Hi,
>>>
>>> I'm currently working on revising scxml-js so that it implements the
>>> semantics defined by the step algorithm of the SCXML specification (as
>>> opposed to the mixture of SCXML semantics and Rhapsody semantics which
>>> it currently implements). I've run into a part of the step algorithm
>>> which is somewhat unclear, and because it may relate to a limitation
>>> in the Commons SCXML implementation, I thought I would ask about this
>>> on the Commons SCXML list before asking about it on the w3-voice list.
>>>
>>> Consider the following SCXML document:
>>>
>>> 
>>>
>>>        
>>>
>>>                
>>>                        
>>>                
>>>
>>>                
>>>                        
>>>                        
>>>                
>>>
>>>                
>>>                        
>>>                        
>>>                
>>>
>>>        
>>>
>>> 
>>>
>>> (https://gist.github.com/846316)
>>>
>>>
>>> I believe the step algorithm in the SCXML specification would
>>> interpret the document in the following way:
>>>
>>> addStatesToEnter would at some point be called for parallel state p.
>>> addStatesToEnter would then be called recursively for each of p's
>>> children: h, A, B.
>>>
>>> addStatesToEnter would first be called for h. Because this is the
>>> first time h was entered, addStatesToEnter will be recursively called
>>> for each of the targets of its default transition: A.2 and B.2. A.2
>>> and B.2 will then be added to statesToEnter.
>>>
>>> addStatesToEnter would then be called for state A. A  is a compound
>>> state, so addStatesToEnter would then be called for A's initial state:
>>> A.1. A.1 would then be added to statesToEnter.
>>>
>>> The same would occur for B, and so B.1 would be added to statesToEnter.
>>>
>>> The resulting configuration would then be: p,h,A,B,A.1,A.2,B.1,B.2,
>>> which is not a legal configuration, as A and B are both OR states.
>>>
>>>
>>>
>>> Is my interpretation of the specification correct, in that the step
>>> algorithm would allow this illegal configuration, or am I missing
>>> something?
>>>
>>>
>>>
>>> I'm asking this question here, rather than on the w3-voice list,
>>> because I believe Commons SCXML does not currently support history in
>>> parallel: 
>>> http://mail-archives.apache.org/mod_mbox/commons-user/201001.mbox/%3cce1f2ea81001131340w2aaaf5bfs84b9db2252287...@mail.gmail.com%3E
>>>
>>> It's not clear whether this is due to possible conflicts in SCXML
>>> semantics, or whether this is simply Commons SCXML implementation
>>> lagging a bit behind changes in the specification.
>>>
>> 
>>
>> Its lag. I believe you have your answer on w3-voice, if not, let me
>> know and I'll look further.
>>
>> -Rahul
>>
>>
>>> I'd appreciate any guidance you can offer. Thanks,
>>>
>>> Jake
>>>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [scxml] semantics of nested history in parallel state

[Jacob Beard]

Please keep an eye on the www-voice thread. I think there may still be
problems with the current step algorithm, and I'm drafting a reply to
elaborate on this.

Thanks,

Jake

On Tue, Mar 1, 2011 at 6:50 PM, Rahul Akolkar  wrote:
> On Sun, Feb 27, 2011 at 11:51 AM, Jacob Beard  wrote:
>> Hi,
>>
>> I'm currently working on revising scxml-js so that it implements the
>> semantics defined by the step algorithm of the SCXML specification (as
>> opposed to the mixture of SCXML semantics and Rhapsody semantics which
>> it currently implements). I've run into a part of the step algorithm
>> which is somewhat unclear, and because it may relate to a limitation
>> in the Commons SCXML implementation, I thought I would ask about this
>> on the Commons SCXML list before asking about it on the w3-voice list.
>>
>> Consider the following SCXML document:
>>
>> 
>>
>>        
>>
>>                
>>                        
>>                
>>
>>                
>>                        
>>                        
>>                
>>
>>                
>>                        
>>                        
>>                
>>
>>        
>>
>> 
>>
>> (https://gist.github.com/846316)
>>
>>
>> I believe the step algorithm in the SCXML specification would
>> interpret the document in the following way:
>>
>> addStatesToEnter would at some point be called for parallel state p.
>> addStatesToEnter would then be called recursively for each of p's
>> children: h, A, B.
>>
>> addStatesToEnter would first be called for h. Because this is the
>> first time h was entered, addStatesToEnter will be recursively called
>> for each of the targets of its default transition: A.2 and B.2. A.2
>> and B.2 will then be added to statesToEnter.
>>
>> addStatesToEnter would then be called for state A. A  is a compound
>> state, so addStatesToEnter would then be called for A's initial state:
>> A.1. A.1 would then be added to statesToEnter.
>>
>> The same would occur for B, and so B.1 would be added to statesToEnter.
>>
>> The resulting configuration would then be: p,h,A,B,A.1,A.2,B.1,B.2,
>> which is not a legal configuration, as A and B are both OR states.
>>
>>
>>
>> Is my interpretation of the specification correct, in that the step
>> algorithm would allow this illegal configuration, or am I missing
>> something?
>>
>>
>>
>> I'm asking this question here, rather than on the w3-voice list,
>> because I believe Commons SCXML does not currently support history in
>> parallel: 
>> http://mail-archives.apache.org/mod_mbox/commons-user/201001.mbox/%3cce1f2ea81001131340w2aaaf5bfs84b9db2252287...@mail.gmail.com%3E
>>
>> It's not clear whether this is due to possible conflicts in SCXML
>> semantics, or whether this is simply Commons SCXML implementation
>> lagging a bit behind changes in the specification.
>>
> 
>
> Its lag. I believe you have your answer on w3-voice, if not, let me
> know and I'll look further.
>
> -Rahul
>
>
>> I'd appreciate any guidance you can offer. Thanks,
>>
>> Jake
>>
>
> -
> 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: [scxml] semantics of nested history in parallel state

[Rahul Akolkar]

On Sun, Feb 27, 2011 at 11:51 AM, Jacob Beard  wrote:
> Hi,
>
> I'm currently working on revising scxml-js so that it implements the
> semantics defined by the step algorithm of the SCXML specification (as
> opposed to the mixture of SCXML semantics and Rhapsody semantics which
> it currently implements). I've run into a part of the step algorithm
> which is somewhat unclear, and because it may relate to a limitation
> in the Commons SCXML implementation, I thought I would ask about this
> on the Commons SCXML list before asking about it on the w3-voice list.
>
> Consider the following SCXML document:
>
> 
>
>        
>
>                
>                        
>                
>
>                
>                        
>                        
>                
>
>                
>                        
>                        
>                
>
>        
>
> 
>
> (https://gist.github.com/846316)
>
>
> I believe the step algorithm in the SCXML specification would
> interpret the document in the following way:
>
> addStatesToEnter would at some point be called for parallel state p.
> addStatesToEnter would then be called recursively for each of p's
> children: h, A, B.
>
> addStatesToEnter would first be called for h. Because this is the
> first time h was entered, addStatesToEnter will be recursively called
> for each of the targets of its default transition: A.2 and B.2. A.2
> and B.2 will then be added to statesToEnter.
>
> addStatesToEnter would then be called for state A. A  is a compound
> state, so addStatesToEnter would then be called for A's initial state:
> A.1. A.1 would then be added to statesToEnter.
>
> The same would occur for B, and so B.1 would be added to statesToEnter.
>
> The resulting configuration would then be: p,h,A,B,A.1,A.2,B.1,B.2,
> which is not a legal configuration, as A and B are both OR states.
>
>
>
> Is my interpretation of the specification correct, in that the step
> algorithm would allow this illegal configuration, or am I missing
> something?
>
>
>
> I'm asking this question here, rather than on the w3-voice list,
> because I believe Commons SCXML does not currently support history in
> parallel: 
> http://mail-archives.apache.org/mod_mbox/commons-user/201001.mbox/%3cce1f2ea81001131340w2aaaf5bfs84b9db2252287...@mail.gmail.com%3E
>
> It's not clear whether this is due to possible conflicts in SCXML
> semantics, or whether this is simply Commons SCXML implementation
> lagging a bit behind changes in the specification.
>


Its lag. I believe you have your answer on w3-voice, if not, let me
know and I'll look further.

-Rahul


> I'd appreciate any guidance you can offer. Thanks,
>
> Jake
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API

[Gilles Sadowski]

Hi.

> It's a debate that goes on. Josh Bloch in his Effective Java book says NPE
> is perfectly acceptable for bad arguments. So it really depends on your
> perspective what an NPE represents. I prefer Josh's opinion but only because
> every single argument probably creates lots of branch-checking that kills
> cpu pipelining.
> 
> > As far as this issue is concerned (for what i have understood) i believe
> > that one way to separate NULL(s) that occur from the A.P.I. from NULL(s)
> > coming from wrong usage of A.P.I. by a user is the assert technique... I
> > didn't know a lot about it but from what i have read it should be
> > implemented only in the private methods of the A.P.I. Check this link out:
> > "
> > http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html";.
> > Another choice is to create a new class that would check all the arguments
> > of every function we are interested in (for example: public
> > checkArguments(Object... args)) [If i have understood correctly the purpose
> > of this issue...]. Any suggestions would be more than welcomed!

NPE is the symptom of a bug.
Using "NullArgumentException" instead of the standard NPE so that the CM
exception hierarchy is singly rooted (the root being "MathRuntimeEception"
in the development version). An advantage is that it is easy to determine
whether an exception is generated by CM. A drawback is that it is
non-standard but this is mitigated by the fact that all other exceptions are
also non-standard (e.g. "MathIllegalArgumentException" instead of IAE).
One has to take into account that we settled on this choice because it makes
it somewhat easier to implement other requirements (namely the localization
of the error messages). It's a compromise (without the localization
requirement, I would have favoured the standard exceptions). And, apart from
avoiding code duplication, this choice has some "features" (which might be
construed as advantages or drawbacks, depending on the viewpoint)...

I'm not sure of what you mean by "branch-checking", but I don't think that
checking for null makes the problem bigger than it would be otherwise, since
CM already checks for many things.

In the end, I'm really not sure what is the best approach for this
particular case. Personally, I'd be happy that the CM code never checks for
null and let the JVM throw NPE. This would hugely simplify the CM code,
albeit at the cost of detecting bad usage a little later. IMHO, it is not a
big deal because the bug is that an object is missing somewhere up the call
stack, and it should be corrected there...

Of course, this would mean that MATH-403 should be dropped, the
"NullArgumentException" class removed, and the policy changed to: "Never
check for null references".


Best,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RESULT][VOTE] Release math 2.2 based on RC6

[Gary Gregory]

Well done! As they say: "It's a process" ;)

Gary

On Tue, Mar 1, 2011 at 3:51 PM, Michael Giannakopoulos  wrote:

> Tremendous effort from all the team! I salute you guys!
>



-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Re: [RESULT][VOTE] Release math 2.2 based on RC6

[Michael Giannakopoulos]

Tremendous effort from all the team! I salute you guys!

Re: [RESULT][VOTE] Release math 2.2 based on RC6

[Simone Tripodi]

congrats for the achievement and the effort you put on this release
Luc, I don't think anybody would beat you ;)
trés bravo, a bientot!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Mar 1, 2011 at 9:36 PM, Luc Maisonobe  wrote:
> Le 01/03/2011 21:31, Luc Maisonobe a écrit :
>> This vote has passed with 7 +1 from the following people:
>
> I'm a little busy right now, so I'll put the artifacts on site tomorrow
> morning (European time) if nobody beats me on it.
>
> Luc
>
>>
>> Luc Maisonobe         (binding)
>> Jörg Schaible         (binding)
>> Oliver Heger          (binding)
>> Phil Steitz           (binding)
>> Dimitri Pourbaix
>> Simone Tripodi        (binding)
>> Mikkel Meyer Andersen
>>
>> Thanks to everybody
>> Luc
>>
>> Le 26/02/2011 20:26, Luc Maisonobe a écrit :
>>> Tag:
>>> 
>>>
>>> All artifacts in Nexus staging repository:
>>> 
>>>
>>> site:
>>> 
>>>
>>> Clirr report:
>>> 
>>>
>>> Votes, please. This vote will close in 72 hours, 2011-03-01T20:00:00 UTC
>>>
>>> [ ] +1 Release these artifacts
>>> [ ] +0 OK, but...
>>> [ ] -0 OK, but really should fix...
>>> [ ] -1 I oppose this release because...
>>>
>>> Thanks!
>>>
>>> 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
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [RESULT][VOTE] Release math 2.2 based on RC6

[Luc Maisonobe]

Le 01/03/2011 21:31, Luc Maisonobe a écrit :
> This vote has passed with 7 +1 from the following people:

I'm a little busy right now, so I'll put the artifacts on site tomorrow
morning (European time) if nobody beats me on it.

Luc

> 
> Luc Maisonobe (binding)
> Jörg Schaible (binding)
> Oliver Heger  (binding)
> Phil Steitz   (binding)
> Dimitri Pourbaix
> Simone Tripodi(binding)
> Mikkel Meyer Andersen
> 
> Thanks to everybody
> Luc
> 
> Le 26/02/2011 20:26, Luc Maisonobe a écrit :
>> Tag:
>> 
>>
>> All artifacts in Nexus staging repository:
>> 
>>
>> site:
>> 
>>
>> Clirr report:
>> 
>>
>> Votes, please. This vote will close in 72 hours, 2011-03-01T20:00:00 UTC
>>
>> [ ] +1 Release these artifacts
>> [ ] +0 OK, but...
>> [ ] -0 OK, but really should fix...
>> [ ] -1 I oppose this release because...
>>
>> Thanks!
>>
>> 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

[RESULT][VOTE] Release math 2.2 based on RC6

[Luc Maisonobe]

This vote has passed with 7 +1 from the following people:

Luc Maisonobe (binding)
Jörg Schaible (binding)
Oliver Heger  (binding)
Phil Steitz   (binding)
Dimitri Pourbaix
Simone Tripodi(binding)
Mikkel Meyer Andersen

Thanks to everybody
Luc

Le 26/02/2011 20:26, Luc Maisonobe a écrit :
> Tag:
> 
> 
> All artifacts in Nexus staging repository:
> 
> 
> site:
> 
> 
> Clirr report:
> 
> 
> Votes, please. This vote will close in 72 hours, 2011-03-01T20:00:00 UTC
> 
> [ ] +1 Release these artifacts
> [ ] +0 OK, but...
> [ ] -0 OK, but really should fix...
> [ ] -1 I oppose this release because...
> 
> Thanks!
> 
> 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

Re: [Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API

[Paul Benedict]

Giannakopoulos,

It's a debate that goes on. Josh Bloch in his Effective Java book says NPE
is perfectly acceptable for bad arguments. So it really depends on your
perspective what an NPE represents. I prefer Josh's opinion but only because
every single argument probably creates lots of branch-checking that kills
cpu pipelining.

Paul

On Tue, Mar 1, 2011 at 2:01 PM, Michael Giannakopoulos  wrote:

> Hello guys,
>
> As far as this issue is concerned (for what i have understood) i believe
> that one way to separate NULL(s) that occur from the A.P.I. from NULL(s)
> coming from wrong usage of A.P.I. by a user is the assert technique... I
> didn't know a lot about it but from what i have read it should be
> implemented only in the private methods of the A.P.I. Check this link out:
> "
> http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html";.
> Another choice is to create a new class that would check all the arguments
> of every function we are interested in (for example: public
> checkArguments(Object... args)) [If i have understood correctly the purpose
> of this issue...]. Any suggestions would be more than welcomed!
>
> Best regards,
> Giannakopoulos Michael
>

[Math - 403] Never propagate a "NullPointerException" resulting from bad usage of the API

[Michael Giannakopoulos]

Hello guys,

As far as this issue is concerned (for what i have understood) i believe
that one way to separate NULL(s) that occur from the A.P.I. from NULL(s)
coming from wrong usage of A.P.I. by a user is the assert technique... I
didn't know a lot about it but from what i have read it should be
implemented only in the private methods of the A.P.I. Check this link out: "
http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html";.
Another choice is to create a new class that would check all the arguments
of every function we are interested in (for example: public
checkArguments(Object... args)) [If i have understood correctly the purpose
of this issue...]. Any suggestions would be more than welcomed!

Best regards,
Giannakopoulos Michael

Re: OGNL as a part of Commons

[Lukasz Lenart]

2011/3/1 Stephen Colebourne :
> Based on what I know of OGNL, it is/was reasonably well used. Trying
> to merge it into another project doesn't help those existing users.

Yep, that's true

> The question is what are the author(s) of OGNL looking for? A home for
> maintainance? The Apache brand? To reinvigorate it? The latter fits
> with a merger into other projects. The former should make commons ask
> if it wants to become a home for maintainance mode (not necessarily a
> bad thing).

A home, right now OGNL is homeless and ownerless. As I know, Struts 2
and Tapestry are both using it extensively.


Kind regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia http://javarsovia.pl

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OGNL as a part of Commons

[Simone Tripodi]

@Stephen: OGNL is currently ownerless, as Lukasz reported, and he's
the only one maintainer on github. Original authors agreed on donating
the to the ASF, I suppose to provide OGNL community the
support/maintainance that deserves. Someone else didn't agree already
on taking in consideration yet another expression language, due to EL
and JEXL already on Commons, that's why we proposed BeanUtils/JEXL. I
would be the first happy on having it as a proper component.

@Paul: sounds reasonable IMHO, even if the OGNL project looks more
like a general purpose expression language, not strictly related to
Struts. Personally there are still good reason to propose OGNL here at
Commons, even if the Struts path would be acceptable


http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Mar 1, 2011 at 7:53 PM, Paul Benedict  wrote:
> Struts 2 is a big consumer of OGNL. The Struts community already consumed
> XWork's IP and now own it. Aren't both of those projects from OpenSymphony?
> If so, I would say it should go over to Struts.
>
> On Tue, Mar 1, 2011 at 12:50 PM, Stephen Colebourne 
> wrote:
>
>> Based on what I know of OGNL, it is/was reasonably well used. Trying
>> to merge it into another project doesn't help those existing users.
>>
>> The question is what are the author(s) of OGNL looking for? A home for
>> maintainance? The Apache brand? To reinvigorate it? The latter fits
>> with a merger into other projects. The former should make commons ask
>> if it wants to become a home for maintainance mode (not necessarily a
>> bad thing).
>>
>> I'm certainly arguing against a straight push into BeanUtils or JEXL.
>>
>> Stephen
>>
>>
>> On 1 March 2011 17:48, Simone Tripodi  wrote:
>> > Hi Henri,
>> > it would be fine for me, I initially suggested BeanUtils because
>> > already support a similar feature[1], but JEXL2 would work as well.
>> > Thanks for your feedbacks, looking forward to collect enough thoughts
>> > to call for a vote :)
>> > Simo
>> >
>> > http://people.apache.org/~simonetripodi/
>> > http://www.99soft.org/
>> >
>> >
>> >
>> > On Tue, Mar 1, 2011 at 6:37 PM, henrib  wrote:
>> >> Howdy;
>> >> I looked at OGNL a while ago and can't fully remember why I ended up
>> using
>> >> JEXL (probably because it seemed simpler). Anyway, OGNL seems very
>> powerful
>> >> and expressive.
>> >> What about trying to merge OGNL & JEXL2 (instead of BeanUtils)? I'm
>> pretty
>> >> sure the core JEXL2 features (introspector - method /static / ctor
>> calls,
>> >> arithmetic) could be leveraged easily. The main differences would be in
>> the
>> >> upper parts I guess (syntax, constructs).
>> >> It probably could help define a better scripting engine and language in
>> the
>> >> future rather than overlapping ones.
>> >> Thoughts ?
>> >> Henrib
>> >>
>> >> --
>> >> View this message in context:
>> http://apache-commons.680414.n4.nabble.com/OGNL-as-a-part-of-Commons-tp3085026p3330241.html
>> >> Sent from the Commons - Dev mailing list archive at Nabble.com.
>> >>
>> >> -
>> >> 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

Re: OGNL as a part of Commons

[Paul Benedict]

Struts 2 is a big consumer of OGNL. The Struts community already consumed
XWork's IP and now own it. Aren't both of those projects from OpenSymphony?
If so, I would say it should go over to Struts.

On Tue, Mar 1, 2011 at 12:50 PM, Stephen Colebourne wrote:

> Based on what I know of OGNL, it is/was reasonably well used. Trying
> to merge it into another project doesn't help those existing users.
>
> The question is what are the author(s) of OGNL looking for? A home for
> maintainance? The Apache brand? To reinvigorate it? The latter fits
> with a merger into other projects. The former should make commons ask
> if it wants to become a home for maintainance mode (not necessarily a
> bad thing).
>
> I'm certainly arguing against a straight push into BeanUtils or JEXL.
>
> Stephen
>
>
> On 1 March 2011 17:48, Simone Tripodi  wrote:
> > Hi Henri,
> > it would be fine for me, I initially suggested BeanUtils because
> > already support a similar feature[1], but JEXL2 would work as well.
> > Thanks for your feedbacks, looking forward to collect enough thoughts
> > to call for a vote :)
> > Simo
> >
> > http://people.apache.org/~simonetripodi/
> > http://www.99soft.org/
> >
> >
> >
> > On Tue, Mar 1, 2011 at 6:37 PM, henrib  wrote:
> >> Howdy;
> >> I looked at OGNL a while ago and can't fully remember why I ended up
> using
> >> JEXL (probably because it seemed simpler). Anyway, OGNL seems very
> powerful
> >> and expressive.
> >> What about trying to merge OGNL & JEXL2 (instead of BeanUtils)? I'm
> pretty
> >> sure the core JEXL2 features (introspector - method /static / ctor
> calls,
> >> arithmetic) could be leveraged easily. The main differences would be in
> the
> >> upper parts I guess (syntax, constructs).
> >> It probably could help define a better scripting engine and language in
> the
> >> future rather than overlapping ones.
> >> Thoughts ?
> >> Henrib
> >>
> >> --
> >> View this message in context:
> http://apache-commons.680414.n4.nabble.com/OGNL-as-a-part-of-Commons-tp3085026p3330241.html
> >> Sent from the Commons - Dev mailing list archive at Nabble.com.
> >>
> >> -
> >> 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: OGNL as a part of Commons

[Stephen Colebourne]

Based on what I know of OGNL, it is/was reasonably well used. Trying
to merge it into another project doesn't help those existing users.

The question is what are the author(s) of OGNL looking for? A home for
maintainance? The Apache brand? To reinvigorate it? The latter fits
with a merger into other projects. The former should make commons ask
if it wants to become a home for maintainance mode (not necessarily a
bad thing).

I'm certainly arguing against a straight push into BeanUtils or JEXL.

Stephen


On 1 March 2011 17:48, Simone Tripodi  wrote:
> Hi Henri,
> it would be fine for me, I initially suggested BeanUtils because
> already support a similar feature[1], but JEXL2 would work as well.
> Thanks for your feedbacks, looking forward to collect enough thoughts
> to call for a vote :)
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Mar 1, 2011 at 6:37 PM, henrib  wrote:
>> Howdy;
>> I looked at OGNL a while ago and can't fully remember why I ended up using
>> JEXL (probably because it seemed simpler). Anyway, OGNL seems very powerful
>> and expressive.
>> What about trying to merge OGNL & JEXL2 (instead of BeanUtils)? I'm pretty
>> sure the core JEXL2 features (introspector - method /static / ctor calls,
>> arithmetic) could be leveraged easily. The main differences would be in the
>> upper parts I guess (syntax, constructs).
>> It probably could help define a better scripting engine and language in the
>> future rather than overlapping ones.
>> Thoughts ?
>> Henrib
>>
>> --
>> View this message in context: 
>> http://apache-commons.680414.n4.nabble.com/OGNL-as-a-part-of-Commons-tp3085026p3330241.html
>> Sent from the Commons - Dev mailing list archive at Nabble.com.
>>
>> -
>> 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: [discuss][Digester] The future of Digester an the Digester3 in sandbox

[Simone Tripodi]

Thanks again for your feedbacks Matt, much more than appreciated! :)

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Mar 1, 2011 at 7:02 PM, Matt Benson  wrote:
>
> On Mar 1, 2011, at 10:22 AM, sebb wrote:
>
>> On 1 March 2011 15:55, Simone Tripodi  wrote:
>>> Hi Seb!
>>> thanks a lot for your hints too, very appreciated!
>>>
>>> Something suggests me to remove the @SuppressWarnings because
>>> ClassCastException are admitted, let's suppose I have the given XML:
>>>
>>> 
>>>    text
>>> 
>>>
>>> that can be mapped to
>>>
>>> class A {
>>>    String prop;
>>> }
>>>
>>> if a user tries to map to a different type
>>>
>>> B b = digester.parse("text");
>>>
>>> An exception has to be thrown.
>>
>> It will be thrown with the generic fix, because the compiler adds a
>> cast to the parse return.
>>
>> However, there is no obvious casting in the above code, so the user
>> may be puzzled by the ClassCastException.
>>
>>> What's the best way to handle that situation?
>>
>> I think the problem is that parse is not really a generic method, and
>> Java does not make the target class available to the method.
>> If you changed the API to add a Class parameter then you could do the
>> check in the parse method.
>> But that might be just as awkward to use.
>>
>> It is obviously nicer to read if the compiler inserts the casts
>> automatically, but the downside is that CCEs can occur when you least
>> expect them.
>>
>> In the sample code, it will happen immediately, but the instance could
>> be stored in a collection and then the CCE might not occur until much
>> later.
>>
>
> This particular "trick" really only applies to such Object foo(...) methods 
> where there are two options for non-generic versions of the code:
>
> 1.  Client calls Object foo = foo(...); if (foo instanceof Foo)...
> 2.  Client calls Foo foo = (Foo) foo(...); potential CCE
>
> My position is that the generic parameter RT casting trick has no effect 
> other than to remove the cast from option 2 above.  If a CCE were going to be 
> raised, it would be raised regardless.  The option 1 idiom is still perfectly 
> valid.
>
> Matt
>
>> Maybe one solution would be to allow the autocasting, but provide a
>> big warning in the Javadoc that it may result in CCEs at any time.
>> For those who don't want to take this risk, there would need to be
>> another version which guaranteed the correct class - or an Exception
>> if that's not possible.
>>
>>> Many thanks in advance, have a nice day!
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>
>>>
>>>
>>> On Tue, Mar 1, 2011 at 4:04 PM, sebb  wrote:
 On 1 March 2011 08:00, Jörg Schaible  wrote:
> Hi Simone,
>
> Simone Tripodi wrote:
>
> [snip]
>
>
>> @SuppressWarnings("unchecked")
>> public  T parse(InputSource input, Class returnedType) throws
>> IOException, SAXException {
>>  .
>>  .
>>  .
>>  return returnedType.cast(this.root);
>> }
>
> It would be nice, if we can start to avoid such method global 
> suppressions,
> because it hides possibly unwanted stuff. You can always assign the
> annotation directly to a variable instead:
>
> @SuppressWarnings("unchecked")
> T t = returnedType.cast(this.root);
> return t;

 I would go a bit further and say that @SuppressWarnings should not be
 used unless you can prove that the cast is always valid (as may well
 be the case here - I've not checked), and that this should be
 documented in a // comment on the annotation, e.g.

 @SuppressWarnings("unchecked") // OK because etc.

 Otherwise, the annotation effectively gives the compiler permission to
 cause a ClassCastException somewhere else at some point in the future.

 As with many forms of suppression, the risk is that there will be a
 bad reaction later ...


> - 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
>>>
>>>
>>
>> -
>> 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

Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox

[Matt Benson]

On Mar 1, 2011, at 10:22 AM, sebb wrote:

> On 1 March 2011 15:55, Simone Tripodi  wrote:
>> Hi Seb!
>> thanks a lot for your hints too, very appreciated!
>> 
>> Something suggests me to remove the @SuppressWarnings because
>> ClassCastException are admitted, let's suppose I have the given XML:
>> 
>> 
>>text
>> 
>> 
>> that can be mapped to
>> 
>> class A {
>>String prop;
>> }
>> 
>> if a user tries to map to a different type
>> 
>> B b = digester.parse("text");
>> 
>> An exception has to be thrown.
> 
> It will be thrown with the generic fix, because the compiler adds a
> cast to the parse return.
> 
> However, there is no obvious casting in the above code, so the user
> may be puzzled by the ClassCastException.
> 
>> What's the best way to handle that situation?
> 
> I think the problem is that parse is not really a generic method, and
> Java does not make the target class available to the method.
> If you changed the API to add a Class parameter then you could do the
> check in the parse method.
> But that might be just as awkward to use.
> 
> It is obviously nicer to read if the compiler inserts the casts
> automatically, but the downside is that CCEs can occur when you least
> expect them.
> 
> In the sample code, it will happen immediately, but the instance could
> be stored in a collection and then the CCE might not occur until much
> later.
> 

This particular "trick" really only applies to such Object foo(...) methods 
where there are two options for non-generic versions of the code:

1.  Client calls Object foo = foo(...); if (foo instanceof Foo)...
2.  Client calls Foo foo = (Foo) foo(...); potential CCE

My position is that the generic parameter RT casting trick has no effect other 
than to remove the cast from option 2 above.  If a CCE were going to be raised, 
it would be raised regardless.  The option 1 idiom is still perfectly valid.

Matt

> Maybe one solution would be to allow the autocasting, but provide a
> big warning in the Javadoc that it may result in CCEs at any time.
> For those who don't want to take this risk, there would need to be
> another version which guaranteed the correct class - or an Exception
> if that's not possible.
> 
>> Many thanks in advance, have a nice day!
>> Simo
>> 
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>> 
>> 
>> 
>> On Tue, Mar 1, 2011 at 4:04 PM, sebb  wrote:
>>> On 1 March 2011 08:00, Jörg Schaible  wrote:
 Hi Simone,
 
 Simone Tripodi wrote:
 
 [snip]
 
 
> @SuppressWarnings("unchecked")
> public  T parse(InputSource input, Class returnedType) throws
> IOException, SAXException {
>  .
>  .
>  .
>  return returnedType.cast(this.root);
> }
 
 It would be nice, if we can start to avoid such method global suppressions,
 because it hides possibly unwanted stuff. You can always assign the
 annotation directly to a variable instead:
 
 @SuppressWarnings("unchecked")
 T t = returnedType.cast(this.root);
 return t;
>>> 
>>> I would go a bit further and say that @SuppressWarnings should not be
>>> used unless you can prove that the cast is always valid (as may well
>>> be the case here - I've not checked), and that this should be
>>> documented in a // comment on the annotation, e.g.
>>> 
>>> @SuppressWarnings("unchecked") // OK because etc.
>>> 
>>> Otherwise, the annotation effectively gives the compiler permission to
>>> cause a ClassCastException somewhere else at some point in the future.
>>> 
>>> As with many forms of suppression, the risk is that there will be a
>>> bad reaction later ...
>>> 
>>> 
 - 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
>> 
>> 
> 
> -
> 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] Error in the Caverphone implemention

[Gary Gregory]

The fix is in SVN and scheduled for inclusion in the upcoming Codec 1.5
release.

Thank you,
Gary

On Tue, Mar 1, 2011 at 6:05 AM, Martin Nybo Andersen  wrote:

> Hi,
>
> On Mon, 28 Feb 2011, Matt Benson wrote:
>
>  Finally, given the fact that we are discussing patches (which have to
>> be granted IP blah blah blah anyway) as well as the fact that you are
>> not subscribed to the developer list, this exchange should be
>> conducted in JIRA.
>>
>> Matt
>>
>
> I wrote the mail to raise a flag. You saw it, which was my intention. I'm
> happy now.
>
> To create a jira account for this minor bug seems to be overkill for me.
> Remember that the harder it is to report a bug, the fewer bugs will be
> reported.
>
> I am not subscribed to this mailing list for the same reason.
>
> What you do with the bug now, is for you to decide.
>
>
>> On Mon, Feb 28, 2011 at 10:04 AM, Gary Gregory 
>> wrote:
>>
>>> Would you be able to include a unit test patch in your diff file?
>>>
>>
> new Caverphone().encode("mbmb") currently returns "MMP111" while it
> should return "MPM111".
>
>
>>> Also, it seems that the examples from
>>>
>>> http://en.wikipedia.org/wiki/Caverphone
>>>
>>> do not match our code:
>>>
>>>{"Lee", "L1"},
>>>{"Thompson", "TMPSN1"},
>>>
>>>
> These Caverphones seems to be version 1. Version 2 which is implemented in
> apache.commons uses 10-letter-codes.
>
>  Hm...
>>>
>>> Thank you,
>>> Gary
>>>
>>> On Mon, Feb 28, 2011 at 8:13 AM, Martin Nybo Andersen >> >wrote:
>>>
>>>  Hi,

 I've found an error in the Caverphone language codec.

 According to the specs at page 2 line 6:
 "If the name ends with mb make it m2".

 Apparently is has been interpreted as:
 "If the name _starts_ with mb make it m2".

 The attached patch will fix it.

 Please CC me, as I'm not subscribed.

>>>
>
> Regards,
> Martin Nybo Andersen




-- 
Thank you,
Gary

http://garygregory.wordpress.com/
http://garygregory.com/
http://people.apache.org/~ggregory/
http://twitter.com/GaryGregory

Re: OGNL as a part of Commons

[Simone Tripodi]

Hi Henri,
it would be fine for me, I initially suggested BeanUtils because
already support a similar feature[1], but JEXL2 would work as well.
Thanks for your feedbacks, looking forward to collect enough thoughts
to call for a vote :)
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Mar 1, 2011 at 6:37 PM, henrib  wrote:
> Howdy;
> I looked at OGNL a while ago and can't fully remember why I ended up using
> JEXL (probably because it seemed simpler). Anyway, OGNL seems very powerful
> and expressive.
> What about trying to merge OGNL & JEXL2 (instead of BeanUtils)? I'm pretty
> sure the core JEXL2 features (introspector - method /static / ctor calls,
> arithmetic) could be leveraged easily. The main differences would be in the
> upper parts I guess (syntax, constructs).
> It probably could help define a better scripting engine and language in the
> future rather than overlapping ones.
> Thoughts ?
> Henrib
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/OGNL-as-a-part-of-Commons-tp3085026p3330241.html
> Sent from the Commons - Dev mailing list archive at Nabble.com.
>
> -
> 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: OGNL as a part of Commons

[henrib]

Howdy;
I looked at OGNL a while ago and can't fully remember why I ended up using
JEXL (probably because it seemed simpler). Anyway, OGNL seems very powerful
and expressive.
What about trying to merge OGNL & JEXL2 (instead of BeanUtils)? I'm pretty
sure the core JEXL2 features (introspector - method /static / ctor calls,
arithmetic) could be leveraged easily. The main differences would be in the
upper parts I guess (syntax, constructs).
It probably could help define a better scripting engine and language in the
future rather than overlapping ones. 
Thoughts ?
Henrib

-- 
View this message in context: 
http://apache-commons.680414.n4.nabble.com/OGNL-as-a-part-of-Commons-tp3085026p3330241.html
Sent from the Commons - Dev mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox

[Simone Tripodi]

Hi Seb,
I think you provided an excellent feedback, I can follow the path you
just showed me and

 * add the warning in the parse() method;
 * provide an aux method, something like checkedParse() that takes the
Class in input and performs the check once document has been parsed.

On a side note, I'd like to collect feedbacks on what all you think
about promoting the sandbox on proper
Many thanks in advance, have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Mar 1, 2011 at 5:22 PM, sebb  wrote:
> On 1 March 2011 15:55, Simone Tripodi  wrote:
>> Hi Seb!
>> thanks a lot for your hints too, very appreciated!
>>
>> Something suggests me to remove the @SuppressWarnings because
>> ClassCastException are admitted, let's suppose I have the given XML:
>>
>> 
>>    text
>> 
>>
>> that can be mapped to
>>
>> class A {
>>    String prop;
>> }
>>
>> if a user tries to map to a different type
>>
>> B b = digester.parse("text");
>>
>> An exception has to be thrown.
>
> It will be thrown with the generic fix, because the compiler adds a
> cast to the parse return.
>
> However, there is no obvious casting in the above code, so the user
> may be puzzled by the ClassCastException.
>
>> What's the best way to handle that situation?
>
> I think the problem is that parse is not really a generic method, and
> Java does not make the target class available to the method.
> If you changed the API to add a Class parameter then you could do the
> check in the parse method.
> But that might be just as awkward to use.
>
> It is obviously nicer to read if the compiler inserts the casts
> automatically, but the downside is that CCEs can occur when you least
> expect them.
>
> In the sample code, it will happen immediately, but the instance could
> be stored in a collection and then the CCE might not occur until much
> later.
>
> Maybe one solution would be to allow the autocasting, but provide a
> big warning in the Javadoc that it may result in CCEs at any time.
> For those who don't want to take this risk, there would need to be
> another version which guaranteed the correct class - or an Exception
> if that's not possible.
>
>> Many thanks in advance, have a nice day!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Tue, Mar 1, 2011 at 4:04 PM, sebb  wrote:
>>> On 1 March 2011 08:00, Jörg Schaible  wrote:
 Hi Simone,

 Simone Tripodi wrote:

 [snip]


> @SuppressWarnings("unchecked")
> public  T parse(InputSource input, Class returnedType) throws
> IOException, SAXException {
>  .
>  .
>  .
>  return returnedType.cast(this.root);
> }

 It would be nice, if we can start to avoid such method global suppressions,
 because it hides possibly unwanted stuff. You can always assign the
 annotation directly to a variable instead:

 @SuppressWarnings("unchecked")
 T t = returnedType.cast(this.root);
 return t;
>>>
>>> I would go a bit further and say that @SuppressWarnings should not be
>>> used unless you can prove that the cast is always valid (as may well
>>> be the case here - I've not checked), and that this should be
>>> documented in a // comment on the annotation, e.g.
>>>
>>> @SuppressWarnings("unchecked") // OK because etc.
>>>
>>> Otherwise, the annotation effectively gives the compiler permission to
>>> cause a ClassCastException somewhere else at some point in the future.
>>>
>>> As with many forms of suppression, the risk is that there will be a
>>> bad reaction later ...
>>>
>>>
 - 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
>>
>>
>
> -
> 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: [discuss][Digester] The future of Digester an the Digester3 in sandbox

[sebb]

On 1 March 2011 15:55, Simone Tripodi  wrote:
> Hi Seb!
> thanks a lot for your hints too, very appreciated!
>
> Something suggests me to remove the @SuppressWarnings because
> ClassCastException are admitted, let's suppose I have the given XML:
>
> 
>    text
> 
>
> that can be mapped to
>
> class A {
>    String prop;
> }
>
> if a user tries to map to a different type
>
> B b = digester.parse("text");
>
> An exception has to be thrown.

It will be thrown with the generic fix, because the compiler adds a
cast to the parse return.

However, there is no obvious casting in the above code, so the user
may be puzzled by the ClassCastException.

> What's the best way to handle that situation?

I think the problem is that parse is not really a generic method, and
Java does not make the target class available to the method.
If you changed the API to add a Class parameter then you could do the
check in the parse method.
But that might be just as awkward to use.

It is obviously nicer to read if the compiler inserts the casts
automatically, but the downside is that CCEs can occur when you least
expect them.

In the sample code, it will happen immediately, but the instance could
be stored in a collection and then the CCE might not occur until much
later.

Maybe one solution would be to allow the autocasting, but provide a
big warning in the Javadoc that it may result in CCEs at any time.
For those who don't want to take this risk, there would need to be
another version which guaranteed the correct class - or an Exception
if that's not possible.

> Many thanks in advance, have a nice day!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Mar 1, 2011 at 4:04 PM, sebb  wrote:
>> On 1 March 2011 08:00, Jörg Schaible  wrote:
>>> Hi Simone,
>>>
>>> Simone Tripodi wrote:
>>>
>>> [snip]
>>>
>>>
 @SuppressWarnings("unchecked")
 public  T parse(InputSource input, Class returnedType) throws
 IOException, SAXException {
  .
  .
  .
  return returnedType.cast(this.root);
 }
>>>
>>> It would be nice, if we can start to avoid such method global suppressions,
>>> because it hides possibly unwanted stuff. You can always assign the
>>> annotation directly to a variable instead:
>>>
>>> @SuppressWarnings("unchecked")
>>> T t = returnedType.cast(this.root);
>>> return t;
>>
>> I would go a bit further and say that @SuppressWarnings should not be
>> used unless you can prove that the cast is always valid (as may well
>> be the case here - I've not checked), and that this should be
>> documented in a // comment on the annotation, e.g.
>>
>> @SuppressWarnings("unchecked") // OK because etc.
>>
>> Otherwise, the annotation effectively gives the compiler permission to
>> cause a ClassCastException somewhere else at some point in the future.
>>
>> As with many forms of suppression, the risk is that there will be a
>> bad reaction later ...
>>
>>
>>> - 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
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox

[Simone Tripodi]

Hi Seb!
thanks a lot for your hints too, very appreciated!

Something suggests me to remove the @SuppressWarnings because
ClassCastException are admitted, let's suppose I have the given XML:


text


that can be mapped to

class A {
String prop;
}

if a user tries to map to a different type

B b = digester.parse("text");

An exception has to be thrown.
What's the best way to handle that situation?
Many thanks in advance, have a nice day!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Mar 1, 2011 at 4:04 PM, sebb  wrote:
> On 1 March 2011 08:00, Jörg Schaible  wrote:
>> Hi Simone,
>>
>> Simone Tripodi wrote:
>>
>> [snip]
>>
>>
>>> @SuppressWarnings("unchecked")
>>> public  T parse(InputSource input, Class returnedType) throws
>>> IOException, SAXException {
>>>  .
>>>  .
>>>  .
>>>  return returnedType.cast(this.root);
>>> }
>>
>> It would be nice, if we can start to avoid such method global suppressions,
>> because it hides possibly unwanted stuff. You can always assign the
>> annotation directly to a variable instead:
>>
>> @SuppressWarnings("unchecked")
>> T t = returnedType.cast(this.root);
>> return t;
>
> I would go a bit further and say that @SuppressWarnings should not be
> used unless you can prove that the cast is always valid (as may well
> be the case here - I've not checked), and that this should be
> documented in a // comment on the annotation, e.g.
>
> @SuppressWarnings("unchecked") // OK because etc.
>
> Otherwise, the annotation effectively gives the compiler permission to
> cause a ClassCastException somewhere else at some point in the future.
>
> As with many forms of suppression, the risk is that there will be a
> bad reaction later ...
>
>
>> - 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: [discuss][Digester] The future of Digester an the Digester3 in sandbox

[sebb]

On 1 March 2011 08:00, Jörg Schaible  wrote:
> Hi Simone,
>
> Simone Tripodi wrote:
>
> [snip]
>
>
>> @SuppressWarnings("unchecked")
>> public  T parse(InputSource input, Class returnedType) throws
>> IOException, SAXException {
>>  .
>>  .
>>  .
>>  return returnedType.cast(this.root);
>> }
>
> It would be nice, if we can start to avoid such method global suppressions,
> because it hides possibly unwanted stuff. You can always assign the
> annotation directly to a variable instead:
>
> @SuppressWarnings("unchecked")
> T t = returnedType.cast(this.root);
> return t;

I would go a bit further and say that @SuppressWarnings should not be
used unless you can prove that the cast is always valid (as may well
be the case here - I've not checked), and that this should be
documented in a // comment on the annotation, e.g.

@SuppressWarnings("unchecked") // OK because etc.

Otherwise, the annotation effectively gives the compiler permission to
cause a ClassCastException somewhere else at some point in the future.

As with many forms of suppression, the risk is that there will be a
bad reaction later ...


> - 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: [discuss][Digester] The future of Digester an the Digester3 in sandbox

[Matt Benson]

On Tue, Mar 1, 2011 at 2:30 AM, Simone Tripodi  wrote:
> Hello Jorg,
> absolutely, thanks a lot for your feedback too, very appreciated!

Point taken, +1.

Matt

> Have a nice day,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Mar 1, 2011 at 9:00 AM, Jörg Schaible
>  wrote:
>> Hi Simone,
>>
>> Simone Tripodi wrote:
>>
>> [snip]
>>
>>
>>> @SuppressWarnings("unchecked")
>>> public  T parse(InputSource input, Class returnedType) throws
>>> IOException, SAXException {
>>>  .
>>>  .
>>>  .
>>>  return returnedType.cast(this.root);
>>> }
>>
>> It would be nice, if we can start to avoid such method global suppressions,
>> because it hides possibly unwanted stuff. You can always assign the
>> annotation directly to a variable instead:
>>
>> @SuppressWarnings("unchecked")
>> T t = returnedType.cast(this.root);
>> return t;
>>
>> - 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: OGNL as a part of Commons

[Simone Tripodi]

>From Commons HP[1] "The Commons is an Apache project focused on all
aspects of reusable Java components" here we use to speak about Math,
Digester, BeanUtils, ... as components and not projects, there are no
exceptions you mentioned.

Moreover, since EL[2] and JXPATH[3] found their home here at commons,
I don't see a different reason for OGNL to live elsewhere.

The legal issue is a problem that needs to be seriously taken in
consideration, BTW AFAIK OGNL left OpenSymphony for a new place[4]
(domain seems to be expired) and Lukasz is the only one OGNL
maintainer - please Lucasz correct me if I'm wrong.

Simo

[1] http://commons.apache.org/
[2] http://commons.apache.org/el/
[3] http://commons.apache.org/jxpath/
[4] http://www.ognl.org/

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Mar 1, 2011 at 1:09 PM, Antonio Petrelli
 wrote:
> 2011/3/1 Antonio Petrelli :
>> 2010/12/13 Lukasz Lenart :
>>> I want to ask you all, is it possible to include OGNL
>>> (https://github.com/jkuhnert/ognl , http://www.opensymphony.com/ognl/
>>> ) into Commons project?
>>
>> Personally I would like to see it as a TLP.
>> AFAIK Apache foundation likes to see one project for one piece of
>> software, Commons is an exception.
>> (I would like to see Commons Math as TLP but this is another story :-D ).
>> IMHO, OGNL is not "common", it is a powerfui expression language.
>> Another option would be the code donation to the nearest project, that
>> I think it is Struts.
>> Anyway, ask the Incubator mailing list, they might help you deciding.
>
> There is another problem: is OpenSymphony willing to donate the code to 
> Apache?
> It's not only a problem of "forking", because the entire copyright
> will pass to Apache, at least for the donated code as it is (the
> copyright will remain to OpenSymphony until the act of donation).
> If not, you cannot donate/incubate at Apache. There are other options
> though, e.g. forking and apache-extras.
>
> Antonio
>
> -
> 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: OGNL as a part of Commons

[Lukasz Lenart]

2011/3/1 Antonio Petrelli :
> There is another problem: is OpenSymphony willing to donate the code to 
> Apache?
> It's not only a problem of "forking", because the entire copyright
> will pass to Apache, at least for the donated code as it is (the
> copyright will remain to OpenSymphony until the act of donation).
> If not, you cannot donate/incubate at Apache. There are other options
> though, e.g. forking and apache-extras.

OGNL was moved to GitHub some time ago and right now it's more or less
ownerless. Before I've started asking you guys, I had been talking to
two main people behind OGNL and they had approved my idea to move OGNL
under ASF umbrella. So, I can send an official request to them to
donate OGNL to ASF if it's needed.


Kind regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia http://javarsovia.pl

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OGNL as a part of Commons

[Antonio Petrelli]

2011/3/1 Antonio Petrelli :
> 2010/12/13 Lukasz Lenart :
>> I want to ask you all, is it possible to include OGNL
>> (https://github.com/jkuhnert/ognl , http://www.opensymphony.com/ognl/
>> ) into Commons project?
>
> Personally I would like to see it as a TLP.
> AFAIK Apache foundation likes to see one project for one piece of
> software, Commons is an exception.
> (I would like to see Commons Math as TLP but this is another story :-D ).
> IMHO, OGNL is not "common", it is a powerfui expression language.
> Another option would be the code donation to the nearest project, that
> I think it is Struts.
> Anyway, ask the Incubator mailing list, they might help you deciding.

There is another problem: is OpenSymphony willing to donate the code to Apache?
It's not only a problem of "forking", because the entire copyright
will pass to Apache, at least for the donated code as it is (the
copyright will remain to OpenSymphony until the act of donation).
If not, you cannot donate/incubate at Apache. There are other options
though, e.g. forking and apache-extras.

Antonio

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [SITE] commons skin and parent snapshots uploaded; please test!

[Simone Tripodi]

Nope, sorry, I only tested replacing the parent pom in mine, I
overlooked your sample. Apologizes.
I tried with both mvn3 and mvn2 but had to suspend the debug due to
job related stuff, I'll continue on the afternoon.
I'll let you know soon!
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Mar 1, 2011 at 12:54 PM, sebb  wrote:
> On 1 March 2011 10:35, Simone Tripodi  wrote:
>> Hi Seb,
>> I just tried upgrading locally the Digester3 parent, but unfortunately
>> mvn is not able to resolve it; this is what happens with mvn3:
>
> Did you use the sample POM I provided?
>
> e.g. save as download.xml and run "mvn -f download.xml"
>
> Which version of Maven are you using?
>
> I've only tried with 2.2.1 so far.
>
>> $ mvn clean site && open target/site/index.html
>> [INFO] Scanning for projects...
>> [ERROR] The build could not read 1 project -> [Help 1]
>> [ERROR]
>> [ERROR]   The project
>> org.apache.commons:commons-digester3:3.0-SNAPSHOT
>> (/Users/simonetripodi/Documents/workspace-opensource/commons-digester3/pom.xml)
>> has 1 error
>> [ERROR]     Non-resolvable parent POM: Could not find artifact
>> org.apache.commons:commons-parent:pom:19-SNAPSHOT and
>> 'parent.relativePath' points at wrong local POM @ line 23, column 13
>> -> [Help 2]
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>> the -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
>> [ERROR] [Help 2]
>> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
>>
>> and this is what happens with mvn2:
>>
>> $ mvn clean site && open target/site/index.html
>> [INFO] Scanning for projects...
>> [INFO] 
>> 
>> [ERROR] FATAL ERROR
>> [INFO] 
>> 
>> [INFO] Error building POM (may not be this project's POM).
>>
>>
>> Project ID: null:commons-digester3:jar:3.0-SNAPSHOT
>>
>> Reason: Cannot find parent: org.apache.commons:commons-parent for
>> project: null:commons-digester3:jar:3.0-SNAPSHOT for project
>> null:commons-digester3:jar:3.0-SNAPSHOT
>>
>>
>> [INFO] 
>> 
>> [INFO] Trace
>> org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
>> org.apache.commons:commons-parent for project:
>> null:commons-digester3:jar:3.0-SNAPSHOT for project
>> null:commons-digester3:jar:3.0-SNAPSHOT
>>        at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:404)
>>        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
>>        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>>        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>>        at 
>> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
>>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>        at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>>        at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>>        at java.lang.reflect.Method.invoke(Method.java:597)
>>        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>>        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>>        at 
>> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>>        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
>> Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
>> find parent: org.apache.commons:commons-parent for project:
>> null:commons-digester3:jar:3.0-SNAPSHOT for project
>> null:commons-digester3:jar:3.0-SNAPSHOT
>>        at 
>> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1396)
>>        at 
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:823)
>>        at 
>> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:508)
>>        at 
>> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200)
>>        at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604)
>>        at 
>> org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487)
>>        at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391)
>>        ... 12 more
>> Caused by: org.apache.maven.project.ProjectBuildingException: POM
>> 'org.apache.commons:commons-parent' not found in repository: Unable to
>> download the artifact from any repository
>>
>>  org.apache.commons:commons-parent:pom:19-SNAPSHOT

Re: OGNL as a part of Commons

[Antonio Petrelli]

2010/12/13 Lukasz Lenart :
> I want to ask you all, is it possible to include OGNL
> (https://github.com/jkuhnert/ognl , http://www.opensymphony.com/ognl/
> ) into Commons project?

Personally I would like to see it as a TLP.
AFAIK Apache foundation likes to see one project for one piece of
software, Commons is an exception.
(I would like to see Commons Math as TLP but this is another story :-D ).
IMHO, OGNL is not "common", it is a powerfui expression language.
Another option would be the code donation to the nearest project, that
I think it is Struts.
Anyway, ask the Incubator mailing list, they might help you deciding.

Antonio

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [SITE] commons skin and parent snapshots uploaded; please test!

[sebb]

On 1 March 2011 10:35, Simone Tripodi  wrote:
> Hi Seb,
> I just tried upgrading locally the Digester3 parent, but unfortunately
> mvn is not able to resolve it; this is what happens with mvn3:

Did you use the sample POM I provided?

e.g. save as download.xml and run "mvn -f download.xml"

Which version of Maven are you using?

I've only tried with 2.2.1 so far.

> $ mvn clean site && open target/site/index.html
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project
> org.apache.commons:commons-digester3:3.0-SNAPSHOT
> (/Users/simonetripodi/Documents/workspace-opensource/commons-digester3/pom.xml)
> has 1 error
> [ERROR]     Non-resolvable parent POM: Could not find artifact
> org.apache.commons:commons-parent:pom:19-SNAPSHOT and
> 'parent.relativePath' points at wrong local POM @ line 23, column 13
> -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with
> the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
>
> and this is what happens with mvn2:
>
> $ mvn clean site && open target/site/index.html
> [INFO] Scanning for projects...
> [INFO] 
> 
> [ERROR] FATAL ERROR
> [INFO] 
> 
> [INFO] Error building POM (may not be this project's POM).
>
>
> Project ID: null:commons-digester3:jar:3.0-SNAPSHOT
>
> Reason: Cannot find parent: org.apache.commons:commons-parent for
> project: null:commons-digester3:jar:3.0-SNAPSHOT for project
> null:commons-digester3:jar:3.0-SNAPSHOT
>
>
> [INFO] 
> 
> [INFO] Trace
> org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
> org.apache.commons:commons-parent for project:
> null:commons-digester3:jar:3.0-SNAPSHOT for project
> null:commons-digester3:jar:3.0-SNAPSHOT
>        at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:404)
>        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
>        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
>        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
>        at 
> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
>        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>        at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>        at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>        at java.lang.reflect.Method.invoke(Method.java:597)
>        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
>        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
>        at 
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
>        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
> find parent: org.apache.commons:commons-parent for project:
> null:commons-digester3:jar:3.0-SNAPSHOT for project
> null:commons-digester3:jar:3.0-SNAPSHOT
>        at 
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1396)
>        at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:823)
>        at 
> org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:508)
>        at 
> org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200)
>        at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604)
>        at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487)
>        at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391)
>        ... 12 more
> Caused by: org.apache.maven.project.ProjectBuildingException: POM
> 'org.apache.commons:commons-parent' not found in repository: Unable to
> download the artifact from any repository
>
>  org.apache.commons:commons-parent:pom:19-SNAPSHOT
>
> from the specified remote repositories:
>  central (http://repo1.maven.org/maven2)
>
>  for project org.apache.commons:commons-parent
>        at 
> org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:605)
>        at 
> org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1392)
>        ... 18 more
> Caused by: org.apache.maven.artifact.resolver.ArtifactNotFou

Re: OGNL as a part of Commons

[Simone Tripodi]

Hi all guys,
I personally like the proposal and think that OGNL is a nice piece of
software that Commons could only benefit if it will join.
As I previously expressed, IMHO OGNL could be merged to BeanUtils that
already supports the same features, but in a less sophisticated way;
BeanUtils could only than benefit from this merge.
Moreover the OGNL project is widely adopted in sever closed/oss
projects, I don't see any potential risk of failure. And it is already
licensed under ASL2.0.
What are your thoughts about it? I'm available on helping Lucasz for
the move and the OGNL community.
Looking forward to see your feedbacks, have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Mar 1, 2011 at 12:41 PM, Lukasz Lenart
 wrote:
> Hi,
>
> So, where I should start ?
>
>
> Kind regards
> --
> Łukasz
> + 48 606 323 122 http://www.lenart.org.pl/
> Kapituła Javarsovia http://javarsovia.pl
>
> -
> 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: OGNL as a part of Commons

[Lukasz Lenart]

Hi,

So, where I should start ?


Kind regards
-- 
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
Kapituła Javarsovia http://javarsovia.pl

-
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

[Gump]

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 113 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: 12 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.003 sec
Running org.apache.commons.proxy.provider.TestConstantProvider
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec
Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 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.014 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.015 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.009 sec
Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory
Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.155 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.003 sec
Running org.apache.commons.proxy.provider.TestBeanProvider
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.02 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: 11 seconds
[INFO] Finished at: Tue Mar 01 10:49:58 UTC 2011
[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: 
http://vmgump.apache.o

[GUMP@vmgump]: Project commons-vfs-test (in module commons-vfs-1.x) failed

[Gump]

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-vfs-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 54 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-vfs-test :  Apache Commons VFS 1.x


Full details are available at:

http://vmgump.apache.org/gump/public/commons-vfs-1.x/commons-vfs-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/commons-vfs-1.x/gump_mvn_settings.xml]
 -DEBUG- (Apache Gump generated) Apache Maven Settings in: 
/srv/gump/public/workspace/commons-vfs-1.x/gump_mvn_settings.xml
 -INFO- Failed with reason build failed
 -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-vfs-1.x/pom.xml
 -INFO- Project Reports in: 
/srv/gump/public/workspace/commons-vfs-1.x/core/target/surefire-reports



The following work was performed:
http://vmgump.apache.org/gump/public/commons-vfs-1.x/commons-vfs-test/gump_work/build_commons-vfs-1.x_commons-vfs-test.html
Work Name: build_commons-vfs-1.x_commons-vfs-test (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 mins 15 secs
Command Line: /opt/maven2/bin/mvn --batch-mode --settings 
/srv/gump/public/workspace/commons-vfs-1.x/gump_mvn_settings.xml package 
[Working Directory: /srv/gump/public/workspace/commons-vfs-1.x]
M2_HOME: /opt/maven2
-
class org.apache.commons.vfs.provider.sftp.test.SftpProviderTestCase is not 
configured for tests, skipping
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec
Running org.apache.commons.vfs.provider.webdav.test.WebdavProviderTestCase
class org.apache.commons.vfs.provider.webdav.test.WebdavProviderTestCase is not 
configured for tests, skipping
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running org.apache.commons.vfs.provider.url.test.UrlProviderTestCase
Mar 1, 2011 10:36:17 AM org.apache.commons.vfs.VfsLog info
INFO: Using 
"/srv/gump/public/workspace/commons-vfs-1.x/core/target/test-classes/test-data/temp"
 as temporary files store.
.
.
.
.
created threads still running:
#1: main
org.apache.commons.vfs.cache.SoftRefFilesCache$SoftRefReleaseThread daemon  
null

Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.237 sec
Running org.apache.commons.vfs.provider.ram.test.CustomRamProviderTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
Running org.apache.commons.vfs.provider.tar.test.NestedTgzTestCase
Mar 1, 2011 10:36:21 AM org.apache.commons.vfs.VfsLog info
INFO: Using 
"/srv/gump/public/workspace/commons-vfs-1.x/core/target/test-classes/test-data/temp"
 as temporary files store.
.
.
.
.
created threads still running:
#1: main
org.apache.commons.vfs.cache.SoftRefFilesCache$SoftRefReleaseThread daemon  
null

Tests run: 56, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.272 sec

Results :

Failed tests: 
  testSetLastModified(org.apache.commons.vfs.test.LastModifiedTests)

Tests run: 975, Failures: 1, Errors: 0, Skipped: 0

[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] There are test failures.

Please refer to 
/srv/gump/public/workspace/commons-vfs-1.x/core/target/surefire-reports for the 
individual test results.
[INFO] 
[INFO] For more information, run Maven with the -e switch
[INFO] 
[INFO] Total time: 2 minutes 14 seconds
[INFO] Finished at: Tue Mar 01 10:36:26 UTC 2011
[INFO] Final Memory: 34M/81M
[INFO] 
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://vmgump.apache.org/gump/public/commons-vfs-1.x/commons-vfs-test/rss.xml
- Atom: 
http://vmgump.apache.org/gump/public/commons-vfs-1.x/commons-vfs-test/atom.xml

== Gump Tracking Only ===
Produced by Apache Gump(TM) version 2.3.
Gump Run 06000601032011, vmgump.apache.org:vmgump:06000601032011
Gump E-mail Identifier (unique within run) #19.

--
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

Re: [SITE] commons skin and parent snapshots uploaded; please test!

[Simone Tripodi]

Hi Seb,
I just tried upgrading locally the Digester3 parent, but unfortunately
mvn is not able to resolve it; this is what happens with mvn3:

$ mvn clean site && open target/site/index.html
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR]   The project
org.apache.commons:commons-digester3:3.0-SNAPSHOT
(/Users/simonetripodi/Documents/workspace-opensource/commons-digester3/pom.xml)
has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact
org.apache.commons:commons-parent:pom:19-SNAPSHOT and
'parent.relativePath' points at wrong local POM @ line 23, column 13
-> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException

and this is what happens with mvn2:

$ mvn clean site && open target/site/index.html
[INFO] Scanning for projects...
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] Error building POM (may not be this project's POM).


Project ID: null:commons-digester3:jar:3.0-SNAPSHOT

Reason: Cannot find parent: org.apache.commons:commons-parent for
project: null:commons-digester3:jar:3.0-SNAPSHOT for project
null:commons-digester3:jar:3.0-SNAPSHOT


[INFO] 
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent:
org.apache.commons:commons-parent for project:
null:commons-digester3:jar:3.0-SNAPSHOT for project
null:commons-digester3:jar:3.0-SNAPSHOT
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:404)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:272)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at 
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot
find parent: org.apache.commons:commons-parent for project:
null:commons-digester3:jar:3.0-SNAPSHOT for project
null:commons-digester3:jar:3.0-SNAPSHOT
at 
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1396)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:823)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:508)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:200)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:604)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:487)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:391)
... 12 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM
'org.apache.commons:commons-parent' not found in repository: Unable to
download the artifact from any repository

  org.apache.commons:commons-parent:pom:19-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)

 for project org.apache.commons:commons-parent
at 
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:605)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1392)
... 18 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException:
Unable to download the artifact from any repository

  org.apache.commons:commons-parent:pom:19-SNAPSHOT

installing locally both the skin and the parent, the code highlighter
doesn't work, even if they are declared in the header. I'm firebugging
to figure out why.

Thanks, have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, Feb 

[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed

[Gump]

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 113 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.53 sec
Running org.apache.commons.scxml.test.TestingTestSuite
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Running org.apache.commons.scxml.env.EnvTestSuite
Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.259 sec
Running org.apache.commons.scxml.SCXMLTestSuite
Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.855 sec <<< 
FAILURE!
Running org.apache.commons.scxml.issues.IssuesTestSuite
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.333 sec
Running org.apache.commons.scxml.model.ModelTestSuite
Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.355 sec <<< 
FAILURE!
Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec
Running org.apache.commons.scxml.semantics.SemanticsTestSuite
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec
Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.049 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.003 sec
Running org.apache.commons.scxml.io.IOTestSuite
Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.372 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: Tue Mar 01 10:08:39 UTC 2011
[INFO] Final Memory: 25M/61M
[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 06000601032011, vmgump.apache.org:vmgump:06000601032011
Gump E-mail Identifier (unique wit

Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox

[Simone Tripodi]

Hello Jorg,
absolutely, thanks a lot for your feedback too, very appreciated!
Have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Tue, Mar 1, 2011 at 9:00 AM, Jörg Schaible
 wrote:
> Hi Simone,
>
> Simone Tripodi wrote:
>
> [snip]
>
>
>> @SuppressWarnings("unchecked")
>> public  T parse(InputSource input, Class returnedType) throws
>> IOException, SAXException {
>>  .
>>  .
>>  .
>>  return returnedType.cast(this.root);
>> }
>
> It would be nice, if we can start to avoid such method global suppressions,
> because it hides possibly unwanted stuff. You can always assign the
> annotation directly to a variable instead:
>
> @SuppressWarnings("unchecked")
> T t = returnedType.cast(this.root);
> return t;
>
> - 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: [discuss][Digester] The future of Digester an the Digester3 in sandbox

[Jörg Schaible]

Hi Simone,

Simone Tripodi wrote:

[snip]


> @SuppressWarnings("unchecked")
> public  T parse(InputSource input, Class returnedType) throws
> IOException, SAXException {
>  .
>  .
>  .
>  return returnedType.cast(this.root);
> }

It would be nice, if we can start to avoid such method global suppressions, 
because it hides possibly unwanted stuff. You can always assign the 
annotation directly to a variable instead:

@SuppressWarnings("unchecked")
T t = returnedType.cast(this.root);
return t;

- Jörg


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org