Re: [VOTE] Release Apache Commons JCS 2.2.1 (roll 2)
On 06.11.17 21:11, Romain Manni-Bucau wrote: > created > http://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2.1-RC2/ > (rev 1814438) Thanks, Romain. However, the POM file in this RC tag contains now --8<-- scm:svn:http://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2.1 scm:svn:https://svn.apache.org/repos/asf/commons/proper/jcs/tags/commons-jcs-2.2.1 http://svn.apache.org/viewvc/commons/proper/jcs/tags/commons-jcs-2.2.1 --8<-- See my point? If you created the RC tag first and then copied, the scm-entries would still point to the RC tag. In this case, it's the other way round. It is difficult for me to see why this is believed to make sense. I'd prefer to match tag name and file content. Bye, Thomas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Fwd: [jira] [Resolved] (CONFIGURATION-675) Add .gitignore file
I do not think we need a JIRA for this kind of housekeeping... Gary -- Forwarded message -- From: Oliver Heger (JIRA) Date: Sat, Nov 11, 2017 at 8:24 AM Subject: [jira] [Resolved] (CONFIGURATION-675) Add .gitignore file To: iss...@commons.apache.org [ https://issues.apache.org/jira/browse/CONFIGURATION-675? page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-675. Resolution: Fixed Fix Version/s: 2.3 Copied the .gitignore file from Commons Lang. Fixed in SVN in revision 1814959. > Add .gitignore file > --- > > Key: CONFIGURATION-675 > URL: https://issues.apache.org/ jira/browse/CONFIGURATION-675 > Project: Commons Configuration > Issue Type: Improvement > Components: Build >Reporter: mingleizhang >Priority: Blocker > Fix For: 2.3 > > > Add .gitignore to this project -- This message was sent by Atlassian JIRA (v6.4.14#64029)
Re: Fwd: [jira] [Resolved] (CONFIGURATION-675) Add .gitignore file
Am 11.11.2017 um 21:22 schrieb Gary Gregory: > I do not think we need a JIRA for this kind of housekeeping... Agreed. However, in this case, the ticket has been created externally, and I just followed the normal workflow to resolve it. Oliver > > Gary > -- Forwarded message -- > From: Oliver Heger (JIRA) > Date: Sat, Nov 11, 2017 at 8:24 AM > Subject: [jira] [Resolved] (CONFIGURATION-675) Add .gitignore file > To: iss...@commons.apache.org > > > > [ https://issues.apache.org/jira/browse/CONFIGURATION-675? > page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] > > Oliver Heger resolved CONFIGURATION-675. > >Resolution: Fixed > Fix Version/s: 2.3 > > Copied the .gitignore file from Commons Lang. Fixed in SVN in revision > 1814959. > >> Add .gitignore file >> --- >> >> Key: CONFIGURATION-675 >> URL: https://issues.apache.org/ > jira/browse/CONFIGURATION-675 >> Project: Commons Configuration >> Issue Type: Improvement >> Components: Build >>Reporter: mingleizhang >>Priority: Blocker >> Fix For: 2.3 >> >> >> Add .gitignore to this project > > > > -- > This message was sent by Atlassian JIRA > (v6.4.14#64029) > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp] update to pool 2.4.3.
I was able to build master commons-dbcp based on commons-pool2 master/2.5.0-SNAPSHOT. All tests pass in both builds :-) Do you have time to push out a release commons-pool2 release? A branch for 2.4.4 or master for 2.5.0, either way would be OK with me. Gary On Fri, Nov 10, 2017 at 2:17 PM, Matt Sicker wrote: > Oh, I may have missed that since it didn't follow the naming scheme of all > the other tags. > > On 10 November 2017 at 13:33, Gary Gregory wrote: > > > I mean "Hi Matt" ! > > > > On Fri, Nov 10, 2017 at 12:32 PM, Gary Gregory > > wrote: > > > > > Hi Amtt, > > > > > > The tags are: > > > > > > POOL_2.4.3 > > > POOL_2.4.3-RC1 > > > > > > Gary > > > > > > On Fri, Nov 10, 2017 at 10:40 AM, Matt Sicker > wrote: > > > > > >> Added in https://issues.apache.org/jira/browse/POOL-335 > > >> > > >> There's no git tag for 2.4.3, so I can't really even find a way to > > >> backport > > >> the option as it is. > > >> > > >> On 5 November 2017 at 22:01, Matt Sicker wrote: > > >> > > >> > I probably can, yeah. Totally slipped my mind about this, though! > > >> > > > >> > On 5 November 2017 at 21:46, Gary Gregory > > >> wrote: > > >> > > > >> >> Hi Matt, > > >> >> > > >> >> Any chance you get take a look this week? > > >> >> > > >> >> Gary > > >> >> > > >> >> On Tue, Oct 31, 2017 at 10:58 AM, Mark Thomas > > >> wrote: > > >> >> > > >> >> > On 31/10/17 14:44, Gary Gregory wrote: > > >> >> > > On Tue, Oct 31, 2017 at 8:33 AM, Matt Sicker > > > >> >> wrote: > > >> >> > > > > >> >> > >> On 31 October 2017 at 04:21, Mark Thomas > > >> wrote: > > >> >> > >>> > > >> >> > >>> If the methods are required then that makes 2.4.3 broken in > my > > >> >> view. In > > >> >> > >>> which case we should wait for 2.4.4 before updating the > version > > >> DBCP > > >> >> > >>> depends on. I don't think we should adapt the test. The test > is > > >> >> telling > > >> >> > >>> us something is broken. We should fix the root cause not > change > > >> the > > >> >> > test. > > >> >> > >>> > > >> >> > >> > > >> >> > >> Regarding this, if the method names were expected in the > output, > > >> >> then a > > >> >> > >> unit test should have existed to verify that. The existing > test > > >> was > > >> >> only > > >> >> > >> checking for class names, so I'm assuming that's why I made > the > > >> >> change a > > >> >> > >> while back to optimize it for that use case. I think I asked > on > > >> the > > >> >> > mailing > > >> >> > >> lists first, but that was a while ago. > > >> >> > >> > > >> >> > > > > >> >> > > It sounds like the missing unit test in [pool] was actually in > > >> [dbcp]! > > >> >> > :-p > > >> >> > > > > >> >> > > Matt or Mark, would you mind pitching in to fill out this > missing > > >> >> test? > > >> >> > > > >> >> > I'll help out when I can but I'm heads down working through the > > >> DAEMON > > >> >> > issues at the moment. It is probably going to be a few days > before > > >> I'm > > >> >> > done there. > > >> >> > > > >> >> > Mark > > >> >> > > > >> >> > > > >> >> > > > > >> >> > > Thank you, > > >> >> > > Gary > > >> >> > > > > >> >> > > > > >> >> > >> > > >> >> > >>> - fix pool > > >> >> > >>> - release pool 2.4.4 > > >> >> > >>> - update DBCP to pool 2.4.4 > > >> >> > >>> - release DBCP > > >> >> > >>> > > >> >> > >> > > >> >> > >> Sounds good to me. This can be done by just removing the > > >> >> SecurityManager > > >> >> > >> version since a StackWalker version of CallStack could be > > >> implemented > > >> >> > for > > >> >> > >> Java 9, so it would be pointless to fully revert the change. > > >> >> > >> > > >> >> > >> -- > > >> >> > >> Matt Sicker > > >> >> > >> > > >> >> > > > > >> >> > > > >> >> > > > >> >> > > > >> - > > >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> >> > For additional commands, e-mail: dev-h...@commons.apache.org > > >> >> > > > >> >> > > > >> >> > > >> > > > >> > > > >> > > > >> > -- > > >> > Matt Sicker > > >> > > > >> > > >> > > >> > > >> -- > > >> Matt Sicker > > >> > > > > > > > > > > > > -- > Matt Sicker >
Re: [dbcp] update to pool 2.4.3.
The last time I tried to RM a Commons project, I had a lot of blockers. I'm not sure if they were all resolved. Anyways, I may have time to try that out tomorrow. Otherwise, most of this week is taken up by a hackathon going on at work. On 11 November 2017 at 14:57, Gary Gregory wrote: > I was able to build master commons-dbcp based on commons-pool2 > master/2.5.0-SNAPSHOT. All tests pass in both builds :-) > > Do you have time to push out a release commons-pool2 release? A branch for > 2.4.4 or master for 2.5.0, either way would be OK with me. > > Gary > > On Fri, Nov 10, 2017 at 2:17 PM, Matt Sicker wrote: > > > Oh, I may have missed that since it didn't follow the naming scheme of > all > > the other tags. > > > > On 10 November 2017 at 13:33, Gary Gregory > wrote: > > > > > I mean "Hi Matt" ! > > > > > > On Fri, Nov 10, 2017 at 12:32 PM, Gary Gregory > > > > wrote: > > > > > > > Hi Amtt, > > > > > > > > The tags are: > > > > > > > > POOL_2.4.3 > > > > POOL_2.4.3-RC1 > > > > > > > > Gary > > > > > > > > On Fri, Nov 10, 2017 at 10:40 AM, Matt Sicker > > wrote: > > > > > > > >> Added in https://issues.apache.org/jira/browse/POOL-335 > > > >> > > > >> There's no git tag for 2.4.3, so I can't really even find a way to > > > >> backport > > > >> the option as it is. > > > >> > > > >> On 5 November 2017 at 22:01, Matt Sicker wrote: > > > >> > > > >> > I probably can, yeah. Totally slipped my mind about this, though! > > > >> > > > > >> > On 5 November 2017 at 21:46, Gary Gregory > > > > >> wrote: > > > >> > > > > >> >> Hi Matt, > > > >> >> > > > >> >> Any chance you get take a look this week? > > > >> >> > > > >> >> Gary > > > >> >> > > > >> >> On Tue, Oct 31, 2017 at 10:58 AM, Mark Thomas > > > >> wrote: > > > >> >> > > > >> >> > On 31/10/17 14:44, Gary Gregory wrote: > > > >> >> > > On Tue, Oct 31, 2017 at 8:33 AM, Matt Sicker < > boa...@gmail.com > > > > > > >> >> wrote: > > > >> >> > > > > > >> >> > >> On 31 October 2017 at 04:21, Mark Thomas > > > >> wrote: > > > >> >> > >>> > > > >> >> > >>> If the methods are required then that makes 2.4.3 broken in > > my > > > >> >> view. In > > > >> >> > >>> which case we should wait for 2.4.4 before updating the > > version > > > >> DBCP > > > >> >> > >>> depends on. I don't think we should adapt the test. The > test > > is > > > >> >> telling > > > >> >> > >>> us something is broken. We should fix the root cause not > > change > > > >> the > > > >> >> > test. > > > >> >> > >>> > > > >> >> > >> > > > >> >> > >> Regarding this, if the method names were expected in the > > output, > > > >> >> then a > > > >> >> > >> unit test should have existed to verify that. The existing > > test > > > >> was > > > >> >> only > > > >> >> > >> checking for class names, so I'm assuming that's why I made > > the > > > >> >> change a > > > >> >> > >> while back to optimize it for that use case. I think I asked > > on > > > >> the > > > >> >> > mailing > > > >> >> > >> lists first, but that was a while ago. > > > >> >> > >> > > > >> >> > > > > > >> >> > > It sounds like the missing unit test in [pool] was actually > in > > > >> [dbcp]! > > > >> >> > :-p > > > >> >> > > > > > >> >> > > Matt or Mark, would you mind pitching in to fill out this > > missing > > > >> >> test? > > > >> >> > > > > >> >> > I'll help out when I can but I'm heads down working through the > > > >> DAEMON > > > >> >> > issues at the moment. It is probably going to be a few days > > before > > > >> I'm > > > >> >> > done there. > > > >> >> > > > > >> >> > Mark > > > >> >> > > > > >> >> > > > > >> >> > > > > > >> >> > > Thank you, > > > >> >> > > Gary > > > >> >> > > > > > >> >> > > > > > >> >> > >> > > > >> >> > >>> - fix pool > > > >> >> > >>> - release pool 2.4.4 > > > >> >> > >>> - update DBCP to pool 2.4.4 > > > >> >> > >>> - release DBCP > > > >> >> > >>> > > > >> >> > >> > > > >> >> > >> Sounds good to me. This can be done by just removing the > > > >> >> SecurityManager > > > >> >> > >> version since a StackWalker version of CallStack could be > > > >> implemented > > > >> >> > for > > > >> >> > >> Java 9, so it would be pointless to fully revert the change. > > > >> >> > >> > > > >> >> > >> -- > > > >> >> > >> Matt Sicker > > > >> >> > >> > > > >> >> > > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> - > > > >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > >> >> > For additional commands, e-mail: dev-h...@commons.apache.org > > > >> >> > > > > >> >> > > > > >> >> > > > >> > > > > >> > > > > >> > > > > >> > -- > > > >> > Matt Sicker > > > >> > > > > >> > > > >> > > > >> > > > >> -- > > > >> Matt Sicker > > > >> > > > > > > > > > > > > > > > > > > > -- > > Matt Sicker > > > -- Matt Sicker
[build-plugin] Re-engineering/release streamlining
Hello all, I was wondering if we might think about a 2.X line in the [build-plugin] to better facilitate our release mechanics so that we don’t have to jump through all of these hoops that we do when building a release candidate? Steps: 1. Move the commons-build-plugin to git. 2. Fully rewrite it so that it retains its site/github templating, but adds functionality to perform our releases in git (maybe withholding svn on purpose to incentivize moving repositories to git). Thoughts? Cheers, -Rob - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [build-plugin] Re-engineering/release streamlining
On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins wrote: > Hello all, > > I was wondering if we might think about a 2.X line in the [build-plugin] > to better facilitate our release mechanics so that we don’t have to jump > through all of these hoops that we do when building a release candidate? > > Steps: > 1. Move the commons-build-plugin to git. > +1 > 2. Fully rewrite it so that it retains its site/github templating, but > adds functionality to perform our releases in git (maybe withholding svn on > purpose to incentivize moving repositories to git). > > Thoughts? > I agree, it's a pain. I wonder if we should step back first and see if we can simplify our release requirements. For example, I find it a huge pain that we have to release to both Nexus and the dist folder. I wonder if we could get away with putting ALL we need in Nexus. After it's all on Apache infra... Gary > > Cheers, > -Rob > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [build-plugin] Re-engineering/release streamlining
> On Nov 11, 2017, at 10:24 PM, Gary Gregory wrote: > >> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins wrote: >> >> Hello all, >> >> I was wondering if we might think about a 2.X line in the [build-plugin] >> to better facilitate our release mechanics so that we don’t have to jump >> through all of these hoops that we do when building a release candidate? >> >> Steps: >> 1. Move the commons-build-plugin to git. >> > > +1 > > >> 2. Fully rewrite it so that it retains its site/github templating, but >> adds functionality to perform our releases in git (maybe withholding svn on >> purpose to incentivize moving repositories to git). >> >> Thoughts? >> > > I agree, it's a pain. I wonder if we should step back first and see if we > can simplify our release requirements. For example, I find it a huge pain > that we have to release to both Nexus and the dist folder. I wonder if we > could get away with putting ALL we need in Nexus. After it's all on Apache > infra... > Sure. What’s the process for changing the requirements? Proposal...vote? I can try to work from the existent requirements, trim some fat, and bring it back for edits. -Rob > Gary > > >> >> Cheers, >> -Rob >> >> >> >> - >> 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: [build-plugin] Re-engineering/release streamlining
On Nov 11, 2017 9:32 PM, "Rob Tompkins" wrote: > On Nov 11, 2017, at 10:24 PM, Gary Gregory wrote: > >> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins wrote: >> >> Hello all, >> >> I was wondering if we might think about a 2.X line in the [build-plugin] >> to better facilitate our release mechanics so that we don’t have to jump >> through all of these hoops that we do when building a release candidate? >> >> Steps: >> 1. Move the commons-build-plugin to git. >> > > +1 > > >> 2. Fully rewrite it so that it retains its site/github templating, but >> adds functionality to perform our releases in git (maybe withholding svn on >> purpose to incentivize moving repositories to git). >> >> Thoughts? >> > > I agree, it's a pain. I wonder if we should step back first and see if we > can simplify our release requirements. For example, I find it a huge pain > that we have to release to both Nexus and the dist folder. I wonder if we > could get away with putting ALL we need in Nexus. After it's all on Apache > infra... > I'm going to go out on a limb and say this won't fly. BUT there is no reason we can't script all this kind of stuff to our hearts' content. Matt Sure. What’s the process for changing the requirements? Proposal...vote? I can try to work from the existent requirements, trim some fat, and bring it back for edits. -Rob > Gary > > >> >> Cheers, >> -Rob >> >> >> >> - >> 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: [build-plugin] Re-engineering/release streamlining
Take a look at how the maven team votes and publishes Chas > On Nov 11, 2017, at 8:26 PM, Matt Benson wrote: > > On Nov 11, 2017 9:32 PM, "Rob Tompkins" wrote: > > > >>> On Nov 11, 2017, at 10:24 PM, Gary Gregory wrote: >>> >>> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins wrote: >>> >>> Hello all, >>> >>> I was wondering if we might think about a 2.X line in the [build-plugin] >>> to better facilitate our release mechanics so that we don’t have to jump >>> through all of these hoops that we do when building a release candidate? >>> >>> Steps: >>> 1. Move the commons-build-plugin to git. >>> >> >> +1 >> >> >>> 2. Fully rewrite it so that it retains its site/github templating, but >>> adds functionality to perform our releases in git (maybe withholding svn > on >>> purpose to incentivize moving repositories to git). >>> >>> Thoughts? >>> >> >> I agree, it's a pain. I wonder if we should step back first and see if we >> can simplify our release requirements. For example, I find it a huge pain >> that we have to release to both Nexus and the dist folder. I wonder if we >> could get away with putting ALL we need in Nexus. After it's all on Apache >> infra... >> > > > I'm going to go out on a limb and say this won't fly. BUT there is no > reason we can't script all this kind of stuff to our hearts' content. > > Matt > > > Sure. What’s the process for changing the requirements? Proposal...vote? I > can try to work from the existent requirements, trim some fat, and bring it > back for edits. > > -Rob > >> Gary >> >> >>> >>> Cheers, >>> -Rob >>> >>> >>> >>> - >>> 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