Re: [discuss][Digester] The future of Digester an the Digester3 in sandbox - Take2
On Wed, Mar 23, 2011 at 6:50 PM, Simone Tripodi wrote: > Hi Matt!!! > I noticed 2 important points I'd like to discuss: > > 1) generally speaking, the bigger part of the users are lazy: they > just want to grab latest released artifact of XXX component with Maven > and use it, so it is hard to obtain feedbacks from APIs not released > yet; > 2) committers/PMCs interested on Digester is reduced: we got two +1s, > one +0 and I didn't express my opinion (If I would have done it, in my > country they would have called me Mafia guy :D ) > > I didn't understand when you wrote "I'm certainly not going to twist > your arm": of course you wouldn't do it physically :D but I didn't > understand in which sense :P > :) Just an expression meaning to try to make you do something against your will. Matt > Have a nice day, all the best! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Wed, Mar 23, 2011 at 1:03 PM, Matt Benson wrote: >> On Wed, Mar 23, 2011 at 6:37 AM, Simone Tripodi >> wrote: >>> Hi all guys, >>> looks like there's not enough activity/interest on new Digester, I >>> suggest to suspend this topic for a while and come speaking about it >>> until there will be interest from the users. >>> Thanks to all that took part of the discussion! >>> All the best, have a nice day, >>> Simo >> >> Personally, I think that just because the users aren't clamoring for >> the new API doesn't mean they wouldn't like it if Digester3 were >> released. At the same time, I'm certainly not going to twist your >> arm. >> >> Matt >> >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Sat, Mar 19, 2011 at 9:51 PM, Simone Tripodi >>> wrote: Hi all, thanks for the trust guys!!! I won't express my vote, it would be too incorrect IMHO. I'll keep my finger crossed to see at least the 3 consensus :) Have a nice weekend! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Mar 19, 2011 at 8:27 PM, Matt Benson wrote: > > On Mar 19, 2011, at 11:05 AM, Rahul Akolkar wrote: > >> On Sat, Mar 19, 2011 at 11:05 AM, Phil Steitz >> wrote: >>> On 3/19/11 4:54 AM, Simone Tripodi wrote: Hi Rahul, thanks once again for the wise suggestions, much more than appreciated! I underestimated the importance of the users over the active developers, so I totally agree with you, moving to dormant is premature. I was aware about breaking APIs compatibility, since we had to face the same problem also in [pool2], I thought it would have been a good idea implementing the sandbox in the o.a.c.digester3[1] package, looks like it is compliant to the suggestions you proposed. I like your idea of branching 1.X, 2.X and put 3 on trunk, shall we call a vote before going on? >>> +1 >>> I don't think we need a VOTE on this, I would say wait a couple of more >>> days to make sure we have (lazy) consensus and then just do it. >>> >> >> >> Not that I care for more process, but I'd like to see 3+ of us say >> this is the API they'd like to see for digester3. We also generally >> require votes for getting stuff out of sandbox so a vote may not be a >> bad idea (even if this isn't a new component, its a new API -- and >> somewhere in there, the lines are blurred). I'm +0. >> > > I hesitate to throw in an opinion as I've never really used digester, but > I quite like the API personally, and would +1 this. > > Matt > >> -Rahul >> >> - >> 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 > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1084776 - /commons/proper/pool/trunk/pom.xml
On 24 March 2011 00:09, Niall Pemberton wrote: > On Thu, Mar 24, 2011 at 12:05 AM, sebb wrote: >> On 23 March 2011 23:37, Simone Tripodi wrote: >>> On Thu, Mar 24, 2011 at 12:28 AM, sebb wrote: On 23 March 2011 23:14, Simone Tripodi wrote: > I think maven best practice would suggest to avoid groupId duplication > - for pool2 we agreed to switch to o.a.c groupId. > which problems are you speaking about? I'm asking because I would have > missed something I don't know yet. I just mean that the POM should specify the groupId even if it is the same as the parent. >>> >>> I still don't understand the reason why it should do it, can you point >>> me to some doc? >> >> AFAIK, there is no such document. >> >> But it's important for people reading the POM to know immediately what >> the groupId is, without having to go searching for the parent. > > There is no need to go searching for the parent. You can just look at > the element's groupId in the POM you're reading. OK, but I still think it's risky to rely on inheritance for such an important value. In theory, the parent might be changed, e.g. to the Apache POM, as used in Common Site Also, having an explicit value documents that the groupId is being intentionally set for this component. > Niall > >>> Many thanks in advance >>> > BTW, the MavenIDE suggested me suppressing the groupId duplication: I think that's unhelpful advice. > Description Resource Path Location Type > GroupId is duplicate of parent > groupId /commons-pool2/pom.xml /commons-pool2 line 28 Maven pom > Loading Problem > > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Wed, Mar 23, 2011 at 11:32 PM, sebb wrote: >> On 23 March 2011 22:09, wrote: >>> Author: simonetripodi >>> Date: Wed Mar 23 22:09:07 2011 >>> New Revision: 1084776 >>> >>> URL: http://svn.apache.org/viewvc?rev=1084776&view=rev >>> Log: >>> groupId inherited from parent pom >> >> That is true, but I think it's best to be specific in this case. >> The wrong groupId can cause lots of problems. >> >>> Modified: >>> commons/proper/pool/trunk/pom.xml >>> >>> Modified: commons/proper/pool/trunk/pom.xml >>> URL: >>> http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?rev=1084776&r1=1084775&r2=1084776&view=diff >>> == >>> --- commons/proper/pool/trunk/pom.xml (original) >>> +++ commons/proper/pool/trunk/pom.xml Wed Mar 23 22:09:07 2011 >>> @@ -25,7 +25,6 @@ >>> 20 >>> >>> 4.0.0 >>> - org.apache.commons >>> commons-pool2 >>> 2.0-SNAPSHOT >>> Commons Pool >>> >>> >>> >> >> - >> 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 >> >> > > - > 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: svn commit: r1084776 - /commons/proper/pool/trunk/pom.xml
On Thu, Mar 24, 2011 at 12:05 AM, sebb wrote: > On 23 March 2011 23:37, Simone Tripodi wrote: >> On Thu, Mar 24, 2011 at 12:28 AM, sebb wrote: >>> On 23 March 2011 23:14, Simone Tripodi wrote: I think maven best practice would suggest to avoid groupId duplication - for pool2 we agreed to switch to o.a.c groupId. which problems are you speaking about? I'm asking because I would have missed something I don't know yet. >>> >>> I just mean that the POM should specify the groupId even if it is the >>> same as the parent. >>> >> >> I still don't understand the reason why it should do it, can you point >> me to some doc? > > AFAIK, there is no such document. > > But it's important for people reading the POM to know immediately what > the groupId is, without having to go searching for the parent. There is no need to go searching for the parent. You can just look at the element's groupId in the POM you're reading. Niall >> Many thanks in advance >> BTW, the MavenIDE suggested me suppressing the groupId duplication: >>> >>> I think that's unhelpful advice. >>> Description Resource Path Location Type GroupId is duplicate of parent groupId /commons-pool2/pom.xml /commons-pool2 line 28 Maven pom Loading Problem http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Mar 23, 2011 at 11:32 PM, sebb wrote: > On 23 March 2011 22:09, wrote: >> Author: simonetripodi >> Date: Wed Mar 23 22:09:07 2011 >> New Revision: 1084776 >> >> URL: http://svn.apache.org/viewvc?rev=1084776&view=rev >> Log: >> groupId inherited from parent pom > > That is true, but I think it's best to be specific in this case. > The wrong groupId can cause lots of problems. > >> Modified: >> commons/proper/pool/trunk/pom.xml >> >> Modified: commons/proper/pool/trunk/pom.xml >> URL: >> http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?rev=1084776&r1=1084775&r2=1084776&view=diff >> == >> --- commons/proper/pool/trunk/pom.xml (original) >> +++ commons/proper/pool/trunk/pom.xml Wed Mar 23 22:09:07 2011 >> @@ -25,7 +25,6 @@ >> 20 >> >> 4.0.0 >> - org.apache.commons >> commons-pool2 >> 2.0-SNAPSHOT >> Commons Pool >> >> >> > > - > 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 > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1084776 - /commons/proper/pool/trunk/pom.xml
On 23 March 2011 23:37, Simone Tripodi wrote: > On Thu, Mar 24, 2011 at 12:28 AM, sebb wrote: >> On 23 March 2011 23:14, Simone Tripodi wrote: >>> I think maven best practice would suggest to avoid groupId duplication >>> - for pool2 we agreed to switch to o.a.c groupId. >>> which problems are you speaking about? I'm asking because I would have >>> missed something I don't know yet. >> >> I just mean that the POM should specify the groupId even if it is the >> same as the parent. >> > > I still don't understand the reason why it should do it, can you point > me to some doc? AFAIK, there is no such document. But it's important for people reading the POM to know immediately what the groupId is, without having to go searching for the parent. > Many thanks in advance > >>> BTW, the MavenIDE suggested me suppressing the groupId duplication: >> >> I think that's unhelpful advice. >> >>> Description Resource Path Location Type >>> GroupId is duplicate of parent >>> groupId /commons-pool2/pom.xml /commons-pool2 line 28 Maven pom >>> Loading Problem >>> >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Wed, Mar 23, 2011 at 11:32 PM, sebb wrote: On 23 March 2011 22:09, wrote: > Author: simonetripodi > Date: Wed Mar 23 22:09:07 2011 > New Revision: 1084776 > > URL: http://svn.apache.org/viewvc?rev=1084776&view=rev > Log: > groupId inherited from parent pom That is true, but I think it's best to be specific in this case. The wrong groupId can cause lots of problems. > Modified: > commons/proper/pool/trunk/pom.xml > > Modified: commons/proper/pool/trunk/pom.xml > URL: > http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?rev=1084776&r1=1084775&r2=1084776&view=diff > == > --- commons/proper/pool/trunk/pom.xml (original) > +++ commons/proper/pool/trunk/pom.xml Wed Mar 23 22:09:07 2011 > @@ -25,7 +25,6 @@ > 20 > > 4.0.0 > - org.apache.commons > commons-pool2 > 2.0-SNAPSHOT > Commons Pool > > > - 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: [LOGGING] latest 1.1.1 release is not a valid OSGi bundle
On Wed, Mar 23, 2011 at 11:55 PM, Simone Tripodi wrote: > Hi all guys, > I just got an error in my OSGi environment because > commons-logging-1.1.1 doesn't have the required OSGi metadata in the > MANIFEST. > Would you agree on releasing a 1.1.2 just to add this metadata? Theres a note on Commons Logging on the following page: http://wiki.apache.org/commons/CommonsOsgi Niall > Many thanks in advance! > Simo > > 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
[LOGGING] latest 1.1.1 release is not a valid OSGi bundle
Hi all guys, I just got an error in my OSGi environment because commons-logging-1.1.1 doesn't have the required OSGi metadata in the MANIFEST. Would you agree on releasing a 1.1.2 just to add this metadata? Many thanks in advance! Simo 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: [discuss][Digester] The future of Digester an the Digester3 in sandbox - Take2
Hi Matt!!! I noticed 2 important points I'd like to discuss: 1) generally speaking, the bigger part of the users are lazy: they just want to grab latest released artifact of XXX component with Maven and use it, so it is hard to obtain feedbacks from APIs not released yet; 2) committers/PMCs interested on Digester is reduced: we got two +1s, one +0 and I didn't express my opinion (If I would have done it, in my country they would have called me Mafia guy :D ) I didn't understand when you wrote "I'm certainly not going to twist your arm": of course you wouldn't do it physically :D but I didn't understand in which sense :P Have a nice day, all the best! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Mar 23, 2011 at 1:03 PM, Matt Benson wrote: > On Wed, Mar 23, 2011 at 6:37 AM, Simone Tripodi > wrote: >> Hi all guys, >> looks like there's not enough activity/interest on new Digester, I >> suggest to suspend this topic for a while and come speaking about it >> until there will be interest from the users. >> Thanks to all that took part of the discussion! >> All the best, have a nice day, >> Simo > > Personally, I think that just because the users aren't clamoring for > the new API doesn't mean they wouldn't like it if Digester3 were > released. At the same time, I'm certainly not going to twist your > arm. > > Matt > >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Sat, Mar 19, 2011 at 9:51 PM, Simone Tripodi >> wrote: >>> Hi all, >>> thanks for the trust guys!!! I won't express my vote, it would be too >>> incorrect IMHO. I'll keep my finger crossed to see at least the 3 >>> consensus :) >>> Have a nice weekend! >>> Simo >>> >>> http://people.apache.org/~simonetripodi/ >>> http://www.99soft.org/ >>> >>> >>> >>> On Sat, Mar 19, 2011 at 8:27 PM, Matt Benson wrote: On Mar 19, 2011, at 11:05 AM, Rahul Akolkar wrote: > On Sat, Mar 19, 2011 at 11:05 AM, Phil Steitz > wrote: >> On 3/19/11 4:54 AM, Simone Tripodi wrote: >>> Hi Rahul, >>> thanks once again for the wise suggestions, much more than appreciated! >>> >>> I underestimated the importance of the users over the active >>> developers, so I totally agree with you, moving to dormant is >>> premature. >>> >>> I was aware about breaking APIs compatibility, since we had to face >>> the same problem also in [pool2], I thought it would have been a good >>> idea implementing the sandbox in the o.a.c.digester3[1] package, looks >>> like it is compliant to the suggestions you proposed. >>> >>> I like your idea of branching 1.X, 2.X and put 3 on trunk, shall we >>> call a vote before going on? >> +1 >> I don't think we need a VOTE on this, I would say wait a couple of more >> days to make sure we have (lazy) consensus and then just do it. >> > > > Not that I care for more process, but I'd like to see 3+ of us say > this is the API they'd like to see for digester3. We also generally > require votes for getting stuff out of sandbox so a vote may not be a > bad idea (even if this isn't a new component, its a new API -- and > somewhere in there, the lines are blurred). I'm +0. > I hesitate to throw in an opinion as I've never really used digester, but I quite like the API personally, and would +1 this. Matt > -Rahul > > - > 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: svn commit: r1084776 - /commons/proper/pool/trunk/pom.xml
On Thu, Mar 24, 2011 at 12:28 AM, sebb wrote: > On 23 March 2011 23:14, Simone Tripodi wrote: >> I think maven best practice would suggest to avoid groupId duplication >> - for pool2 we agreed to switch to o.a.c groupId. >> which problems are you speaking about? I'm asking because I would have >> missed something I don't know yet. > > I just mean that the POM should specify the groupId even if it is the > same as the parent. > I still don't understand the reason why it should do it, can you point me to some doc? Many thanks in advance >> BTW, the MavenIDE suggested me suppressing the groupId duplication: > > I think that's unhelpful advice. > >> Description Resource Path Location Type >> GroupId is duplicate of parent >> groupId /commons-pool2/pom.xml /commons-pool2 line 28 Maven pom >> Loading Problem >> >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Wed, Mar 23, 2011 at 11:32 PM, sebb wrote: >>> On 23 March 2011 22:09, wrote: Author: simonetripodi Date: Wed Mar 23 22:09:07 2011 New Revision: 1084776 URL: http://svn.apache.org/viewvc?rev=1084776&view=rev Log: groupId inherited from parent pom >>> >>> That is true, but I think it's best to be specific in this case. >>> The wrong groupId can cause lots of problems. >>> Modified: commons/proper/pool/trunk/pom.xml Modified: commons/proper/pool/trunk/pom.xml URL: http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?rev=1084776&r1=1084775&r2=1084776&view=diff == --- commons/proper/pool/trunk/pom.xml (original) +++ commons/proper/pool/trunk/pom.xml Wed Mar 23 22:09:07 2011 @@ -25,7 +25,6 @@ 20 4.0.0 - org.apache.commons commons-pool2 2.0-SNAPSHOT Commons Pool >>> >>> - >>> 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: svn commit: r1084776 - /commons/proper/pool/trunk/pom.xml
On 23 March 2011 23:14, Simone Tripodi wrote: > I think maven best practice would suggest to avoid groupId duplication > - for pool2 we agreed to switch to o.a.c groupId. > which problems are you speaking about? I'm asking because I would have > missed something I don't know yet. I just mean that the POM should specify the groupId even if it is the same as the parent. > BTW, the MavenIDE suggested me suppressing the groupId duplication: I think that's unhelpful advice. > Description Resource Path Location Type > GroupId is duplicate of parent > groupId /commons-pool2/pom.xml /commons-pool2 line 28 Maven pom > Loading Problem > > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Wed, Mar 23, 2011 at 11:32 PM, sebb wrote: >> On 23 March 2011 22:09, wrote: >>> Author: simonetripodi >>> Date: Wed Mar 23 22:09:07 2011 >>> New Revision: 1084776 >>> >>> URL: http://svn.apache.org/viewvc?rev=1084776&view=rev >>> Log: >>> groupId inherited from parent pom >> >> That is true, but I think it's best to be specific in this case. >> The wrong groupId can cause lots of problems. >> >>> Modified: >>> commons/proper/pool/trunk/pom.xml >>> >>> Modified: commons/proper/pool/trunk/pom.xml >>> URL: >>> http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?rev=1084776&r1=1084775&r2=1084776&view=diff >>> == >>> --- commons/proper/pool/trunk/pom.xml (original) >>> +++ commons/proper/pool/trunk/pom.xml Wed Mar 23 22:09:07 2011 >>> @@ -25,7 +25,6 @@ >>> 20 >>> >>> 4.0.0 >>> - org.apache.commons >>> commons-pool2 >>> 2.0-SNAPSHOT >>> Commons Pool >>> >>> >>> >> >> - >> 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: svn commit: r1084776 - /commons/proper/pool/trunk/pom.xml
I think maven best practice would suggest to avoid groupId duplication - for pool2 we agreed to switch to o.a.c groupId. which problems are you speaking about? I'm asking because I would have missed something I don't know yet. BTW, the MavenIDE suggested me suppressing the groupId duplication: Description ResourcePathLocationType GroupId is duplicate of parent groupId /commons-pool2/pom.xml /commons-pool2 line 28 Maven pom Loading Problem http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Mar 23, 2011 at 11:32 PM, sebb wrote: > On 23 March 2011 22:09, wrote: >> Author: simonetripodi >> Date: Wed Mar 23 22:09:07 2011 >> New Revision: 1084776 >> >> URL: http://svn.apache.org/viewvc?rev=1084776&view=rev >> Log: >> groupId inherited from parent pom > > That is true, but I think it's best to be specific in this case. > The wrong groupId can cause lots of problems. > >> Modified: >> commons/proper/pool/trunk/pom.xml >> >> Modified: commons/proper/pool/trunk/pom.xml >> URL: >> http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?rev=1084776&r1=1084775&r2=1084776&view=diff >> == >> --- commons/proper/pool/trunk/pom.xml (original) >> +++ commons/proper/pool/trunk/pom.xml Wed Mar 23 22:09:07 2011 >> @@ -25,7 +25,6 @@ >> 20 >> >> 4.0.0 >> - org.apache.commons >> commons-pool2 >> 2.0-SNAPSHOT >> Commons Pool >> >> >> > > - > 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: [VOTE][SITE] Release Commons Skin 3 and Commons Parent 19 - cancelled
On Fri, Mar 11, 2011 at 11:50 PM, Niall Pemberton wrote: > On Fri, Mar 11, 2011 at 11:38 PM, Niall Pemberton > wrote: >> On Fri, Mar 11, 2011 at 4:34 PM, sebb wrote: >>> On 11 March 2011 09:42, Niall Pemberton wrote: On Fri, Mar 11, 2011 at 3:37 AM, sebb wrote: > On 11 March 2011 01:17, sebb wrote: >> On 10 March 2011 22:32, Niall Pemberton >> wrote: >>> The "rc" profile doesn't seem to create the source/binary assemblies >>> any more. Not sure what's caused this, but for releases not using >>> Nexus this is an issue. >> >> AFAIK, that's not something that was changed between 18 => 19 is it? >> When did it last work? > > I've just tried "mvn clean -Prc package -DskipTests" in NET with > Parent 17, 18, 19-SNAPSHOT and they all generate the assemblies. > > What component are you testing with, and what command are you using? I tried it on commons-chain using "mvn -Prc install" - but maybe I made a mistake. I'll try it again when I get home tonight. >>> >>> I just tried, and the change seems to have happened between Parent 17 >>> and Parent 18. >>> Not sure why that should cause the change. >> >> maven-assembly-plugin was upgraded from 2.2-beta-5 to 2.2. Reverting >> back fixes this for chain. There is version 2.2.1 of that plugin, but >> it didn't resolve the issue. >> >> I'll try and see if I can find out the cause. > > OK slightly bizarre - I tried 2.2.1 of the assembly plugin again and > it downloaded a whole load of stuff - so perhaps I made a mistake and > hadn't tested against it. Seems now though, that it works with either > 2.2 or 2.2.1, so I'm not sure whats going on :( > > Anyway, I've changed the version and now it works. I encountered this issue again with version 20 of commons-parent, but I found that "mvn -Prc package" doesn't work, but "mvn -Prc clean package" works correctly. The assembly plugin doesn't run in the first scenario, but does in the second. Not sure why, but if I had to guess it would be that the clean plugin is causing a different version of a common dependency to be pulled in. Niall > Niall > >> Niall >> >>> But it may just be an issue with some components, because NET works OK. >>> Niall >>> Niall >>> >>> On Thu, Mar 10, 2011 at 4:57 PM, sebb wrote: I'm abandoning this vote, because changes are needed to skin: - logos now mostly have TMs, so need to change default and parent - don't claim Commons as a trademark I'll start a new vote later. If there are any other issues which have not been reported, please do so ASAP so I can incorporate any fixes in the next round of voting. On 7 March 2011 20:47, sebb wrote: > I think the time has come to formally vote on the updates to Commons > Skin and Commons Parent. > > Maven artifacts: > > https://repository.apache.org/content/repositories/orgapachecommons-008/org/apache/commons/ > > SVN > https://svn.apache.org/repos/asf/commons/proper/commons-skin/tags/commons-skin-3-RC2/ > and > https://svn.apache.org/repos/asf/commons/proper/commons-parent/tags/commons-parent-19-RC2/ > > Commons Skin 3 changes > === > - commons parent 5 => 18 > - added support for code prettify > - site.css now uses relative url for referencing css files, so offline > sites work better > - added template to support trademark footer; also supports > $relativePath resolution; adds TM overlay support; allows absolute > URLs in banner elements > > Commons Parent 19 changes > == > - Apache Parent Pom 7=> 9 > - maven-antrun-plugin 1.3 => 1.5 > - antrun config: change deprecated to > - site plugin 2.0.1 => 2.2 > - surefire 2.7.1 => 2.7.2 > - javadoc 2.5 => 2.7 > - add AL header to site.xml > - use local copy of commons-logo, rather than linking to commons.a.o > - always use absolute link for http://commons.a.o/ > - commons skin 2=>3 > - added prettify css/javascript to improve source code formatting > - license now points to http://www.apache.org/licenses/ as per > branding guidelines > - synchronise common menu items with commons-site > - moved ApacheCon logo under ASF menu, and made it clickable > - added trademark references to page footers > - added TM symbol overlays to banner images > > Note that Commons Parent depends on Commons Skin 3. > > Commons Skin 3 based on RC2 > === > > [ ] +1 > [ ] -1, because: > > Commons Parent 19 based on RC2 > == > >>
Re: svn commit: r1084776 - /commons/proper/pool/trunk/pom.xml
On 23 March 2011 22:09, wrote: > Author: simonetripodi > Date: Wed Mar 23 22:09:07 2011 > New Revision: 1084776 > > URL: http://svn.apache.org/viewvc?rev=1084776&view=rev > Log: > groupId inherited from parent pom That is true, but I think it's best to be specific in this case. The wrong groupId can cause lots of problems. > Modified: > commons/proper/pool/trunk/pom.xml > > Modified: commons/proper/pool/trunk/pom.xml > URL: > http://svn.apache.org/viewvc/commons/proper/pool/trunk/pom.xml?rev=1084776&r1=1084775&r2=1084776&view=diff > == > --- commons/proper/pool/trunk/pom.xml (original) > +++ commons/proper/pool/trunk/pom.xml Wed Mar 23 22:09:07 2011 > @@ -25,7 +25,6 @@ > 20 > > 4.0.0 > - org.apache.commons > commons-pool2 > 2.0-SNAPSHOT > Commons Pool > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1084642 - /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
On 3/23/11 2:01 PM, Mark Thomas wrote: > On 23/03/2011 17:46, Phil Steitz wrote: >> Do we need to worry about leaking memory here due to things never >> getting removed from _poolMap, _poolList? > I don't think so. The entries should only exit in _poolMap and _poolList > while associated objects exist. > Looking carefully at both 1.5.5 and 1.5.x current code, I can see the situation is better now; but I still can't see _poolMap reliably cleaned up if clear is invoked when an instance failing validation is in process of being destroyed. I am not sure there is an easy way to fix this, since we need to keep the _poolMap entry around to keep accounting correct. Phil >> Also, IIUC what is going on here, we need to make a similar change >> the evict() where the last instance in a keyed pool is evicted. > It certainly looks like it. However, this is highlighting some issues (I > think in the tests). I'll try and look at this tomorrow. > > Mark > > - > 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: svn commit: r1084642 - /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
On 23/03/2011 17:46, Phil Steitz wrote: > Do we need to worry about leaking memory here due to things never > getting removed from _poolMap, _poolList? I don't think so. The entries should only exit in _poolMap and _poolList while associated objects exist. > Also, IIUC what is going on here, we need to make a similar change > the evict() where the last instance in a keyed pool is evicted. It certainly looks like it. However, this is highlighting some issues (I think in the tests). I'll try and look at this tomorrow. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL] Ready for 1.5.6
On 23/03/2011 19:54, Phil Steitz wrote: > On 3/23/11 12:36 PM, Mark Thomas wrote: >> Phil, >> >> I believe all the pool issues for 1.5.x have been resolved. Over to >> you... :) >> > Thanks! You are awesome, Mark! > > I will finish reviewing your last set of commits and then roll an RC. > > Did you see my (hopefully baseless) memory leak fear about the fix > for POOL-181? I just did. My mail was slow this afternoon. Looking at it now. I think a few changes will be required. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [POOL] Ready for 1.5.6
On 3/23/11 12:36 PM, Mark Thomas wrote: > Phil, > > I believe all the pool issues for 1.5.x have been resolved. Over to > you... :) > Thanks! You are awesome, Mark! I will finish reviewing your last set of commits and then roll an RC. Did you see my (hopefully baseless) memory leak fear about the fix for POOL-181? Phil > Mark > > - > 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
[POOL] Ready for 1.5.6
Phil, I believe all the pool issues for 1.5.x have been resolved. Over to you... :) Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r1084642 - /commons/proper/pool/trunk/src/java/org/apache/commons/pool2/impl/GenericKeyedObjectPool.java
Do we need to worry about leaking memory here due to things never getting removed from _poolMap, _poolList? Also, IIUC what is going on here, we need to make a similar change the evict() where the last instance in a keyed pool is evicted. Thanks for fixing this. Phil - 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 - Take2
On Wed, Mar 23, 2011 at 6:37 AM, Simone Tripodi wrote: > Hi all guys, > looks like there's not enough activity/interest on new Digester, I > suggest to suspend this topic for a while and come speaking about it > until there will be interest from the users. > Thanks to all that took part of the discussion! > All the best, have a nice day, > Simo Personally, I think that just because the users aren't clamoring for the new API doesn't mean they wouldn't like it if Digester3 were released. At the same time, I'm certainly not going to twist your arm. Matt > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Sat, Mar 19, 2011 at 9:51 PM, Simone Tripodi > wrote: >> Hi all, >> thanks for the trust guys!!! I won't express my vote, it would be too >> incorrect IMHO. I'll keep my finger crossed to see at least the 3 >> consensus :) >> Have a nice weekend! >> Simo >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Sat, Mar 19, 2011 at 8:27 PM, Matt Benson wrote: >>> >>> On Mar 19, 2011, at 11:05 AM, Rahul Akolkar wrote: >>> On Sat, Mar 19, 2011 at 11:05 AM, Phil Steitz wrote: > On 3/19/11 4:54 AM, Simone Tripodi wrote: >> Hi Rahul, >> thanks once again for the wise suggestions, much more than appreciated! >> >> I underestimated the importance of the users over the active >> developers, so I totally agree with you, moving to dormant is >> premature. >> >> I was aware about breaking APIs compatibility, since we had to face >> the same problem also in [pool2], I thought it would have been a good >> idea implementing the sandbox in the o.a.c.digester3[1] package, looks >> like it is compliant to the suggestions you proposed. >> >> I like your idea of branching 1.X, 2.X and put 3 on trunk, shall we >> call a vote before going on? > +1 > I don't think we need a VOTE on this, I would say wait a couple of more > days to make sure we have (lazy) consensus and then just do it. > Not that I care for more process, but I'd like to see 3+ of us say this is the API they'd like to see for digester3. We also generally require votes for getting stuff out of sandbox so a vote may not be a bad idea (even if this isn't a new component, its a new API -- and somewhere in there, the lines are blurred). I'm +0. >>> >>> I hesitate to throw in an opinion as I've never really used digester, but I >>> quite like the API personally, and would +1 this. >>> >>> Matt >>> -Rahul - 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: [DBCP] The plan for v2
On 23/03/2011 11:00, Simone Tripodi wrote: > Thanks a lot Mark, much more than appreciated :) > I'm +1 to support your idea of moving the current pool2 code in a > branch, then continue the 1.5.5 work. The useful part that IMHO can be > backported are the use of generics, replacing primitive constants with > enumerations, removing some useless wrappers in the PoolUtils class > such the checked pool (we agreed pools are checked due the generics > adoption) and the synchronized pools (they can be implemented via > Proxies). > The rest of the design "improvement" can be ignored, I'm not convinced > at all that current code contains the APIs I would like to use as a > user. > > I don't have an idea yet on how to introduce java.util.concurrent, I > guess there are betters contributors in this area. > > BTW count on me, I should be able to replicate the code modifications > in a short while (1 night should be enough :P) Brilliant. I'll fix the remaining 1.5.x issues first so we are in a position to do a 1.5.6 release and then I'll look at doing the re-organising. The DBCP backlog looks rather larger so I may create dbcp2 before all of them get fixed. I'll see how things go. Mark - 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 - Take2
Hi all guys, looks like there's not enough activity/interest on new Digester, I suggest to suspend this topic for a while and come speaking about it until there will be interest from the users. Thanks to all that took part of the discussion! All the best, have a nice day, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Sat, Mar 19, 2011 at 9:51 PM, Simone Tripodi wrote: > Hi all, > thanks for the trust guys!!! I won't express my vote, it would be too > incorrect IMHO. I'll keep my finger crossed to see at least the 3 > consensus :) > Have a nice weekend! > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Sat, Mar 19, 2011 at 8:27 PM, Matt Benson wrote: >> >> On Mar 19, 2011, at 11:05 AM, Rahul Akolkar wrote: >> >>> On Sat, Mar 19, 2011 at 11:05 AM, Phil Steitz wrote: On 3/19/11 4:54 AM, Simone Tripodi wrote: > Hi Rahul, > thanks once again for the wise suggestions, much more than appreciated! > > I underestimated the importance of the users over the active > developers, so I totally agree with you, moving to dormant is > premature. > > I was aware about breaking APIs compatibility, since we had to face > the same problem also in [pool2], I thought it would have been a good > idea implementing the sandbox in the o.a.c.digester3[1] package, looks > like it is compliant to the suggestions you proposed. > > I like your idea of branching 1.X, 2.X and put 3 on trunk, shall we > call a vote before going on? +1 I don't think we need a VOTE on this, I would say wait a couple of more days to make sure we have (lazy) consensus and then just do it. >>> >>> >>> Not that I care for more process, but I'd like to see 3+ of us say >>> this is the API they'd like to see for digester3. We also generally >>> require votes for getting stuff out of sandbox so a vote may not be a >>> bad idea (even if this isn't a new component, its a new API -- and >>> somewhere in there, the lines are blurred). I'm +0. >>> >> >> I hesitate to throw in an opinion as I've never really used digester, but I >> quite like the API personally, and would +1 this. >> >> Matt >> >>> -Rahul >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 156 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: 13 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.011 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.157 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.028 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: 12 seconds [INFO] Finished at: Wed Mar 23 11:18:49 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.
Re: [DBCP] The plan for v2
Thanks a lot Mark, much more than appreciated :) I'm +1 to support your idea of moving the current pool2 code in a branch, then continue the 1.5.5 work. The useful part that IMHO can be backported are the use of generics, replacing primitive constants with enumerations, removing some useless wrappers in the PoolUtils class such the checked pool (we agreed pools are checked due the generics adoption) and the synchronized pools (they can be implemented via Proxies). The rest of the design "improvement" can be ignored, I'm not convinced at all that current code contains the APIs I would like to use as a user. I don't have an idea yet on how to introduce java.util.concurrent, I guess there are betters contributors in this area. BTW count on me, I should be able to replicate the code modifications in a short while (1 night should be enough :P) Have a nice day, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Mar 23, 2011 at 10:41 AM, Mark Thomas wrote: > On 23/03/2011 08:33, Simone Tripodi wrote: >> Hi all, >> sorry to join late the conversation but looks like living in a >> different timezone *is* an issue :( > > No need to apologise. I wasn't going to go ahead until you had a chance > to give your feedback. > >> I am the person "physically" responsable of the pool2 "big >> refactoring" and I would be very sorry to see all that work dropped or >> be useless; if you follow the old pool2 discussion in this ML that >> drove the refactoring, you would maybe agree that I'm not just a crazy >> guy :) > > I did follow it and I broadly agreed with each of the steps. What I > hadn't truly appreciated was how much things had changed and the work > that would be required to get a dbcp2 working with it. > >> BTW I agree with Gary vision, things would have worked simpler just >> adding the generics in pool-1.X and releasing as 2.0, then applying >> changes/merging fixes step by step, releasing "early and often" >> following the XP best practice. > > I think there is general agreement here that small steps are good. > >> Can I still be helpful here? I would be much more than happy to use >> the pool2 with generics ASAP, so it's part of my interest too :) > > Absolutely! If we do go down the POOL_FUTURE + backport route I'm sure > there will be plenty of discussion about some of the backports as well > as the work on dbcp2. Any and all help would be appreciated. > > If you have any thoughts on the best way to get from where we are to a > dbcp2 that uses pool2 where the core pooling code has been updated to > take advantage of java.util.concurrent then please do share them. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[GUMP@vmgump]: Project commons-scxml-test (in module apache-commons) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-scxml-test has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 156 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.566 sec Running org.apache.commons.scxml.test.TestingTestSuite Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.019 sec Running org.apache.commons.scxml.env.EnvTestSuite Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.174 sec Running org.apache.commons.scxml.SCXMLTestSuite Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.929 sec <<< FAILURE! Running org.apache.commons.scxml.issues.IssuesTestSuite Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.331 sec Running org.apache.commons.scxml.model.ModelTestSuite Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 2.197 sec <<< FAILURE! Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec Running org.apache.commons.scxml.semantics.SemanticsTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.039 sec Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.01 sec Running org.apache.commons.scxml.io.IOTestSuite Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.336 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: Wed Mar 23 10:04:06 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 06000623032011, vmgump.apache.org:vmgump:06000623032011 Gump E-mail Identifier (unique wit
[GUMP@vmgump]: Project commons-vfs2 (in module apache-commons) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-vfs2 has an issue affecting its community integration.
This issue affects 7 projects,
and has been outstanding for 39 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- commons-configuration : Apache Commons
- commons-configuration-test : Apache Commons
- commons-vfs2 : Apache Commons
- commons-vfs2-sandbox : Apache Commons
- commons-vfs2-test : Apache Commons
- jakarta-turbine-jcs : Cache
- jcs : Cache
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-vfs2-*[0-9T].jar] identifier set to project
name
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/vfs/pom.xml
-INFO- Failed to extract fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/gump_work/build_apache-commons_commons-vfs2.html
Work Name: build_apache-commons_commons-vfs2 (Type: Build)
Work ended in a state of : Failed
Elapsed: 32 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml package
[Working Directory: /srv/gump/public/workspace/apache-commons/vfs]
M2_HOME: /opt/maven2
-
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[move] Moving 2 files to
/srv/gump/public/workspace/apache-commons/vfs/core/target/test-classes/test-data/code
[INFO] Executed tasks
[WARNING] DEPRECATED [systemProperties]: Use systemPropertyVariables instead.
[INFO] [surefire:test {execution: default-test}]
[INFO] Tests are skipped.
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar:
/srv/gump/public/workspace/apache-commons/vfs/core/target/commons-vfs2-2.0-SNAPSHOT.jar
[INFO] [jar:test-jar {execution: default}]
[INFO] Building jar:
/srv/gump/public/workspace/apache-commons/vfs/core/target/commons-vfs2-2.0-SNAPSHOT-tests.jar
[INFO]
[INFO] Building Commons VFS Examples
[INFO]task-segment: [package]
[INFO]
[INFO] [antrun:run {execution: javadoc.resources}]
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource to META-INF
[INFO] Copying 1 resource to META-INF
[INFO] [compiler:compile {execution: default-compile}]
[INFO] Compiling 5 source files to
/srv/gump/public/workspace/apache-commons/vfs/examples/target/classes
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/srv/gump/public/workspace/apache-commons/vfs/examples/src/main/java/org/apache/commons/vfs2/libcheck/FtpCheck.java:[75,46]
cannot find symbol
symbol : method getSystemName()
location: class org.apache.commons.net.ftp.FTPClient
[INFO] 1error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/srv/gump/public/workspace/apache-commons/vfs/examples/src/main/java/org/apache/commons/vfs2/libcheck/FtpCheck.java:[75,46]
cannot find symbol
symbol : method getSystemName()
location: class org.apache.commons.net.ftp.FTPClient
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 31 seconds
[INFO] Finished at: Wed Mar 23 09:53:12 UTC 2011
[INFO] Final Memory: 46M/110M
[INFO]
-
To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/rss.xml
- Atom:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs2/atom.xml
=
Re: [DBCP] The plan for v2
On 23/03/2011 08:33, Simone Tripodi wrote: > Hi all, > sorry to join late the conversation but looks like living in a > different timezone *is* an issue :( No need to apologise. I wasn't going to go ahead until you had a chance to give your feedback. > I am the person "physically" responsable of the pool2 "big > refactoring" and I would be very sorry to see all that work dropped or > be useless; if you follow the old pool2 discussion in this ML that > drove the refactoring, you would maybe agree that I'm not just a crazy > guy :) I did follow it and I broadly agreed with each of the steps. What I hadn't truly appreciated was how much things had changed and the work that would be required to get a dbcp2 working with it. > BTW I agree with Gary vision, things would have worked simpler just > adding the generics in pool-1.X and releasing as 2.0, then applying > changes/merging fixes step by step, releasing "early and often" > following the XP best practice. I think there is general agreement here that small steps are good. > Can I still be helpful here? I would be much more than happy to use > the pool2 with generics ASAP, so it's part of my interest too :) Absolutely! If we do go down the POOL_FUTURE + backport route I'm sure there will be plenty of discussion about some of the backports as well as the work on dbcp2. Any and all help would be appreciated. If you have any thoughts on the best way to get from where we are to a dbcp2 that uses pool2 where the core pooling code has been updated to take advantage of java.util.concurrent then please do share them. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [DBCP] The plan for v2
Hi all, sorry to join late the conversation but looks like living in a different timezone *is* an issue :( I am the person "physically" responsable of the pool2 "big refactoring" and I would be very sorry to see all that work dropped or be useless; if you follow the old pool2 discussion in this ML that drove the refactoring, you would maybe agree that I'm not just a crazy guy :) BTW I agree with Gary vision, things would have worked simpler just adding the generics in pool-1.X and releasing as 2.0, then applying changes/merging fixes step by step, releasing "early and often" following the XP best practice. Can I still be helpful here? I would be much more than happy to use the pool2 with generics ASAP, so it's part of my interest too :) Have a nice day, all the best, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Mar 22, 2011 at 8:24 PM, Mark Thomas wrote: > On 22/03/2011 18:52, Phil Steitz wrote: >> On 3/22/11 11:20 AM, Mark Thomas wrote: > >> I don't >>> mind working with a moving target as long as it is moving towards a >>> clear goal. That goal for me is: >>> - Java 5 / generics >>> - fixing inconsistencies / oddities >>> - improved performance on DBCP in multi-core servers. >> +1 >> >> Does the first item include replacing the wait/notify stuff with >> j.util.concurrent primitives? > > Yes, in combination with the third item. > >>> It would certainly make starting dbcp2 a whole lot easier if most of the >>> pool2 re-factoring had not taken place. I think we made a mistake in not >>> pushing forward with DBCP and POOL in parallel. That said, I like a lot >>> of the pool2 changes and don't want to throw them away. >>> >>> What do folks think to the following: >>> - move pool trunk to a POOL_FUTURE branch >>> - restore pool trunk to a copy of the POOL_1_X branch >>> - rename pool package to o.a.c.pool2 >>> (in reality this would probably be a merge from POOL_FUTURE) >>> - rename dbcp packages to o.a.c.dbcp2 >>> - get pool2 and dbcp2 working together >>> - get Tomcat trunk working with dbcp2 >>> - go through the POOL_FUTURE changes one at a time: >>> - merging it into pool2 trunk >>> - updating dbcp2 trunk if necessary >>> - testing updated dbcp2 with Tomcat >>> - if a POOL_FUTURE change breaks DBCP/Tomcat integration in a way that >>> can't easily be fixed skip that change and leave it in POOL_FUTURE >> I am fine with above, though I don't think there are any >> incompatible changes yet in the POOL_1_X branch or dbcp trunk, so >> steps 5 and 6 above are no-ops. > > Not quite no-ops. There will be some imports to rename but that should > be the limit of it. > >> I also don't want to be a stick in >> the mud, but it would be great to close the handful of issues open >> against POOL_1_X and cut a 1.5.5 before the copy so we could avoid >> having to port fixes. I will cut the release if we can agree on the >> fixes. Same holds for DBCP. A little concerted effort could get >> 1.3.1/1.4.1 out before cutting the new branch. > > That makes sense to me. It also gives folks a chance to chime in with > their views on the plan. > > Mark > > > - > 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
