You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2012/06/17 09:49:33 UTC
[pool] 2.0 release
Looks like only the relatively trivial POOL-220 and POOL-217 affect
2.0. We need to resolve these and do some javadoc and site
cleanup; but unless there are other things we want to get into 2.0,
I would like to move this toward a release. I will volunteer to RM
if no one else wants to. Is there anything else we need to do
code-wise to get this ready?
Phil
P.S.: I seem to have lost my commons JIRA karma (can't edit
issues). Can someone restore that, please?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by Gary Gregory <ga...@gmail.com>.
As general note, releasing is hard, error prone and cumbersome. I just
don't know what to do about it. The whole 'site in SVN' thing is
interesting. Maybe it's a direction worth pursuing for more than just
the site, not sure.
Gary
On Jun 23, 2012, at 21:05, sebb <se...@gmail.com> wrote:
> On 23 June 2012 23:00, Phil Steitz <ph...@gmail.com> wrote:
>> On 6/17/12 2:20 PM, Mark Thomas wrote:
>>> On 17/06/2012 16:26, Phil Steitz wrote:
>>>> On 6/17/12 1:13 AM, Mark Thomas wrote:
>>>>> On 17/06/2012 08:49, Phil Steitz wrote:
>>>>>> Looks like only the relatively trivial POOL-220 and POOL-217 affect
>>>>>> 2.0.
>>>>> +1
>>>>>
>>>>>> We need to resolve these and do some javadoc and site
>>>>>> cleanup; but unless there are other things we want to get into 2.0,
>>>>>> I would like to move this toward a release. I will volunteer to RM
>>>>>> if no one else wants to. Is there anything else we need to do
>>>>>> code-wise to get this ready?
>>>>> I don't think so. I got most things cleaned up before I became
>>>>> distracted (for far longer than I expected) by a Tomcat 7 release.
>>>>>
>>>>> The Tomcat 7 release is almost done, so I should be able to spend some
>>>>> time on POOL 2 / DBCP 2 in the coming weeks.
>>> The two open issues for 2.x have been fixed. That leaves one
>>> enhancement, one 1.x specific issue and one issue that doesn't as yet
>>> have a satisfactory explanation. I think the code is ready for a 2.0
>>> release. A lot of the supporting material isn't.
>>
>> I will get to work on that. Patches welcome, of course :)
>>
>> I will also start testing with dbcp2 to make sure all is well. Are
>> we reasonably confident that we will not need any further API
>> changes to pool2 for dbcp2?
>>>
>>>> Great. If there are things I can help with or areas of dicyness [1]
>>>> in need of extra testing, let me know.
>>> I don't think any one part is dicer than any other. Having the existing
>>> test suite has really helped.
>>>
>>> If I had to pick on something, it would be the improved concurrency.
>>> Since that is the new bit, that is where the current test cases may ber
>>> lacking.
>>
>> I am fixing [performance] up to work fully with [pool] 2 and to
>> leverage the new stats reporting.
>>
>> One question for the list: is it still possible to release commons
>> components "manually" to the maven repos - i.e., without using Nexus
>
> No.
>
> The only way to the repo is via Nexus staging.
>
>> or the release plugin?
>
> Yes.
>
> You don't need to use the release plugin.
> I never have used it, and I've been RM for Net and CP etc.
>
> Just need to use "mvn deploy" with the appropriate profile and flags.
>
>
>>
>> Phil
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by sebb <se...@gmail.com>.
On 24 June 2012 15:12, Oliver Heger <ol...@oliver-heger.de> wrote:
> Am 24.06.2012 03:05, schrieb sebb:
>
>> On 23 June 2012 23:00, Phil Steitz <ph...@gmail.com> wrote:
>>>
>>> On 6/17/12 2:20 PM, Mark Thomas wrote:
>>>>
>>>> On 17/06/2012 16:26, Phil Steitz wrote:
>>>>>
>>>>> On 6/17/12 1:13 AM, Mark Thomas wrote:
>>>>>>
>>>>>> On 17/06/2012 08:49, Phil Steitz wrote:
>>>>>>>
>>>>>>> Looks like only the relatively trivial POOL-220 and POOL-217 affect
>>>>>>> 2.0.
>>>>>>
>>>>>> +1
>>>>>>
>>>>>>> We need to resolve these and do some javadoc and site
>>>>>>> cleanup; but unless there are other things we want to get into 2.0,
>>>>>>> I would like to move this toward a release. I will volunteer to RM
>>>>>>> if no one else wants to. Is there anything else we need to do
>>>>>>> code-wise to get this ready?
>>>>>>
>>>>>> I don't think so. I got most things cleaned up before I became
>>>>>> distracted (for far longer than I expected) by a Tomcat 7 release.
>>>>>>
>>>>>> The Tomcat 7 release is almost done, so I should be able to spend some
>>>>>> time on POOL 2 / DBCP 2 in the coming weeks.
>>>>
>>>> The two open issues for 2.x have been fixed. That leaves one
>>>> enhancement, one 1.x specific issue and one issue that doesn't as yet
>>>> have a satisfactory explanation. I think the code is ready for a 2.0
>>>> release. A lot of the supporting material isn't.
>>>
>>>
>>> I will get to work on that. Patches welcome, of course :)
>>>
>>> I will also start testing with dbcp2 to make sure all is well. Are
>>> we reasonably confident that we will not need any further API
>>> changes to pool2 for dbcp2?
>>>>
>>>>
>>>>> Great. If there are things I can help with or areas of dicyness [1]
>>>>> in need of extra testing, let me know.
>>>>
>>>> I don't think any one part is dicer than any other. Having the existing
>>>> test suite has really helped.
>>>>
>>>> If I had to pick on something, it would be the improved concurrency.
>>>> Since that is the new bit, that is where the current test cases may ber
>>>> lacking.
>>>
>>>
>>> I am fixing [performance] up to work fully with [pool] 2 and to
>>> leverage the new stats reporting.
>>>
>>> One question for the list: is it still possible to release commons
>>> components "manually" to the maven repos - i.e., without using Nexus
>>
>>
>> No.
>>
>> The only way to the repo is via Nexus staging.
>
>
> Does this mean that the instructions on
> http://commons.apache.org/releases/index.html are outdated and do not work
> any more?
Some parts are outdated, some are not.
For example Nexus makes a difference.
I've been meaning to update them for ages...
> Oliver
>
>
>>
>>> or the release plugin?
>>
>>
>> Yes.
>>
>> You don't need to use the release plugin.
>> I never have used it, and I've been RM for Net and CP etc.
>>
>> Just need to use "mvn deploy" with the appropriate profile and flags.
>>
>>
>>>
>>> Phil
>>>>
>>>>
>>>> Mark
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by Phil Steitz <ph...@gmail.com>.
On 6/24/12 1:38 PM, Mark Thomas wrote:
> On 24/06/2012 20:41, Phil Steitz wrote:
>> On 6/24/12 12:00 PM, sebb wrote:
>>> Nexus does not prevent any of this; it is a staging repo.
>> It does block what used to be a simple, controlled process
>>
>> 0) generate, test and sign artifacts locally
>> 1) upload to p.a.o
>> 2) vote
>> 3) move to release locations
>>
>> Now you need to count on maven to "deploy" to the staging repo and
>> then move things across the network somehow to /dist.
>>
>> Unless, as you point out below, you make the actual release
>> artifacts first and then "publish" to maven central separately.
>> Unfortunately, that ends up requiring two votes, because you can't
>> just move stuff into the staging repo (unless there is some way to
>> do that, which would be great).
> This is doable. The Tomcat project already does this. See [1]. You want
> to follow the deploy-release target. With the added bonus that this
> script does not require passwords to be stored locally anywhere, whether
> 'encrypted' or not.
>
> There are a couple of manual steps (see the README in the same
> directory) required to get to a release but the fundamental requirement
> (you have some JARs stored somewhere (locally, p.a.o, wherever) that
> you want in Maven central) is met by this process.
Thanks, Mark! Looks like this will work.
Phil
>
> HTH,
>
> Mark
>
> [1] http://svn.apache.org/repos/asf/tomcat/trunk/res/maven/mvn-pub.xml
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by Mark Thomas <ma...@apache.org>.
On 24/06/2012 20:41, Phil Steitz wrote:
> On 6/24/12 12:00 PM, sebb wrote:
>> Nexus does not prevent any of this; it is a staging repo.
>
> It does block what used to be a simple, controlled process
>
> 0) generate, test and sign artifacts locally
> 1) upload to p.a.o
> 2) vote
> 3) move to release locations
>
> Now you need to count on maven to "deploy" to the staging repo and
> then move things across the network somehow to /dist.
>
> Unless, as you point out below, you make the actual release
> artifacts first and then "publish" to maven central separately.
> Unfortunately, that ends up requiring two votes, because you can't
> just move stuff into the staging repo (unless there is some way to
> do that, which would be great).
This is doable. The Tomcat project already does this. See [1]. You want
to follow the deploy-release target. With the added bonus that this
script does not require passwords to be stored locally anywhere, whether
'encrypted' or not.
There are a couple of manual steps (see the README in the same
directory) required to get to a release but the fundamental requirement
(you have some JARs stored somewhere (locally, p.a.o, wherever) that
you want in Maven central) is met by this process.
HTH,
Mark
[1] http://svn.apache.org/repos/asf/tomcat/trunk/res/maven/mvn-pub.xml
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by Phil Steitz <ph...@gmail.com>.
On 6/24/12 3:29 PM, sebb wrote:
> On 24 June 2012 20:41, Phil Steitz <ph...@gmail.com> wrote:
>> On 6/24/12 12:00 PM, sebb wrote:
>>> On 24 June 2012 15:41, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 6/24/12 7:12 AM, Oliver Heger wrote:
>>>>> Am 24.06.2012 03:05, schrieb sebb:
>>>>>> On 23 June 2012 23:00, Phil Steitz <ph...@gmail.com> wrote:
>>>>>>> On 6/17/12 2:20 PM, Mark Thomas wrote:
>>>>>>>> On 17/06/2012 16:26, Phil Steitz wrote:
>>>>>>>>> On 6/17/12 1:13 AM, Mark Thomas wrote:
>>>>>>>>>> On 17/06/2012 08:49, Phil Steitz wrote:
>>>>>>>>>>> Looks like only the relatively trivial POOL-220 and POOL-217
>>>>>>>>>>> affect
>>>>>>>>>>> 2.0.
>>>>>>>>>> +1
>>>>>>>>>>
>>>>>>>>>>> We need to resolve these and do some javadoc and site
>>>>>>>>>>> cleanup; but unless there are other things we want to get
>>>>>>>>>>> into 2.0,
>>>>>>>>>>> I would like to move this toward a release. I will
>>>>>>>>>>> volunteer to RM
>>>>>>>>>>> if no one else wants to. Is there anything else we need to do
>>>>>>>>>>> code-wise to get this ready?
>>>>>>>>>> I don't think so. I got most things cleaned up before I became
>>>>>>>>>> distracted (for far longer than I expected) by a Tomcat 7
>>>>>>>>>> release.
>>>>>>>>>>
>>>>>>>>>> The Tomcat 7 release is almost done, so I should be able to
>>>>>>>>>> spend some
>>>>>>>>>> time on POOL 2 / DBCP 2 in the coming weeks.
>>>>>>>> The two open issues for 2.x have been fixed. That leaves one
>>>>>>>> enhancement, one 1.x specific issue and one issue that doesn't
>>>>>>>> as yet
>>>>>>>> have a satisfactory explanation. I think the code is ready for
>>>>>>>> a 2.0
>>>>>>>> release. A lot of the supporting material isn't.
>>>>>>> I will get to work on that. Patches welcome, of course :)
>>>>>>>
>>>>>>> I will also start testing with dbcp2 to make sure all is well. Are
>>>>>>> we reasonably confident that we will not need any further API
>>>>>>> changes to pool2 for dbcp2?
>>>>>>>>> Great. If there are things I can help with or areas of
>>>>>>>>> dicyness [1]
>>>>>>>>> in need of extra testing, let me know.
>>>>>>>> I don't think any one part is dicer than any other. Having the
>>>>>>>> existing
>>>>>>>> test suite has really helped.
>>>>>>>>
>>>>>>>> If I had to pick on something, it would be the improved
>>>>>>>> concurrency.
>>>>>>>> Since that is the new bit, that is where the current test cases
>>>>>>>> may ber
>>>>>>>> lacking.
>>>>>>> I am fixing [performance] up to work fully with [pool] 2 and to
>>>>>>> leverage the new stats reporting.
>>>>>>>
>>>>>>> One question for the list: is it still possible to release commons
>>>>>>> components "manually" to the maven repos - i.e., without using
>>>>>>> Nexus
>>>>>> No.
>>>>>>
>>>>>> The only way to the repo is via Nexus staging.
>>>>> Does this mean that the instructions on
>>>>> http://commons.apache.org/releases/index.html are outdated and do
>>>>> not work any more?
>>>> Yes, that's what that means, at least for the uploading to mvn repos
>>>> bit, and unless we can find a creative way to circumvent nexus,
>>>> there appears to be no way to generate the release artifacts
>>>> packages locally, inspect them, and keep them on p.a.o for voting
>>>> and release. Unless we decide to separate the maven repo publishing
>>>> step, which I may be inclined to do for [pool] 2. The steps to get
>>>> the real distro (source and binary tars and zips) to the mirrors
>>>> should still work, modulo some pom hacking to work around plugin
>>>> regressions.
>>> Nexus does not prevent any of this; it is a staging repo.
>> It does block what used to be a simple, controlled process
>>
>> 0) generate, test and sign artifacts locally
>> 1) upload to p.a.o
>> 2) vote
>> 3) move to release locations
> This is much what one does now, where:
>
> 1) use maven to deploy to staging repo
My problem with that is that I have to depend on setting fiddling
and good luck to ensure something like what I want to release ends
up in a location that I can point a VOTE to. I don't get to review
the artifacts locally or control what manner of cruft gets pushed
out with them.
>
>> Now you need to count on maven to "deploy" to the staging repo and
>> then move things across the network somehow to /dist.
>>
>> Unless, as you point out below, you make the actual release
>> artifacts first and then "publish" to maven central separately.
> Not sure I follow that.
What the process Mark described will do. Seems a good compromise.
>
>> Unfortunately, that ends up requiring two votes, because you can't
>> just move stuff into the staging repo (unless there is some way to
>> do that, which would be great).
> No, it only requires one vote, which is on the artifacts in the staging repo.
>
>>> Note that Maven does not know anything about Nexus; Maven deploys to
>>> the staging area which happens to be managed by Nexus.
>>>
>>> The non-Maven archives can either be deployed with the Maven jars to
>>> Nexus, and then the vote held on the combined set of archives,
>>> or the non-Maven archives can be deployed to a separate holding area.
>>>
>>> If using a combined staging area, the non-Maven stuff needs to be
>>> copied dist/ (and deleted from the staging area) before the Maven
>>> stuff is released.
>>> [I had hoped that Nexus could be tweaked to do this automatically but
>>> this has not happened]
>>>
>>> Nexus does not fundamentally change the release process, its main
>>> benefit is that it makes it harder to publish Maven artifacts
>>> accidentally, as happened a lot of times before it was introduced.
>> Only once in Commons, IIRC, due to an RM not following the "manual"
>> process and running with scissors using the release plugin.
> Just done a quick check of 3 projects at random:
>
> http://central.maven.org/maven2/commons-jexl/commons-jexl/
> http://central.maven.org/maven2/commons-lang/commons-lang/
> http://central.maven.org/maven2/commons-net/commons-net/
>
> Have a look at those directories; I'm pretty sure no-one really voted
> on release version "20030307.151331".
>
> Looks like snapshot versions were somehow released as full versions.
That goes way back to the maven 1 days before maven repos were
controlled in any way and is a consequence of the "you can't delete
anything" policy from the ibiblio days. Back in the early m1 days,
people (not necessarily even associated with Commons) pushed out and
depended on snapshots somewhat randomly. We asked later if we could
eliminate them, but were told we could not.
>
> It seems unlikely that version 1.0-RC1 was ever intended for release either.
>
>>> Nexus also takes care of maintaining the Maven metadata, and ensuring
>>> that the files are created in the correct directory.
>> Trival and easy to verify as part of the release prep and vote.
> This is not a process I would describe as trivial.
Well, I never had a problem doing it with simple scripts and would
trade the control and assured success for the minor inconvenience
any day.
Phil
>
>> Phil
>>>> Phil
>>>>> Oliver
>>>>>
>>>>>>> or the release plugin?
>>>>>> Yes.
>>>>>>
>>>>>> You don't need to use the release plugin.
>>>>>> I never have used it, and I've been RM for Net and CP etc.
>>>>>>
>>>>>> Just need to use "mvn deploy" with the appropriate profile and
>>>>>> flags.
>>>>>>
>>>>>>
>>>>>>> Phil
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by sebb <se...@gmail.com>.
On 24 June 2012 20:41, Phil Steitz <ph...@gmail.com> wrote:
> On 6/24/12 12:00 PM, sebb wrote:
>> On 24 June 2012 15:41, Phil Steitz <ph...@gmail.com> wrote:
>>> On 6/24/12 7:12 AM, Oliver Heger wrote:
>>>> Am 24.06.2012 03:05, schrieb sebb:
>>>>> On 23 June 2012 23:00, Phil Steitz <ph...@gmail.com> wrote:
>>>>>> On 6/17/12 2:20 PM, Mark Thomas wrote:
>>>>>>> On 17/06/2012 16:26, Phil Steitz wrote:
>>>>>>>> On 6/17/12 1:13 AM, Mark Thomas wrote:
>>>>>>>>> On 17/06/2012 08:49, Phil Steitz wrote:
>>>>>>>>>> Looks like only the relatively trivial POOL-220 and POOL-217
>>>>>>>>>> affect
>>>>>>>>>> 2.0.
>>>>>>>>> +1
>>>>>>>>>
>>>>>>>>>> We need to resolve these and do some javadoc and site
>>>>>>>>>> cleanup; but unless there are other things we want to get
>>>>>>>>>> into 2.0,
>>>>>>>>>> I would like to move this toward a release. I will
>>>>>>>>>> volunteer to RM
>>>>>>>>>> if no one else wants to. Is there anything else we need to do
>>>>>>>>>> code-wise to get this ready?
>>>>>>>>> I don't think so. I got most things cleaned up before I became
>>>>>>>>> distracted (for far longer than I expected) by a Tomcat 7
>>>>>>>>> release.
>>>>>>>>>
>>>>>>>>> The Tomcat 7 release is almost done, so I should be able to
>>>>>>>>> spend some
>>>>>>>>> time on POOL 2 / DBCP 2 in the coming weeks.
>>>>>>> The two open issues for 2.x have been fixed. That leaves one
>>>>>>> enhancement, one 1.x specific issue and one issue that doesn't
>>>>>>> as yet
>>>>>>> have a satisfactory explanation. I think the code is ready for
>>>>>>> a 2.0
>>>>>>> release. A lot of the supporting material isn't.
>>>>>> I will get to work on that. Patches welcome, of course :)
>>>>>>
>>>>>> I will also start testing with dbcp2 to make sure all is well. Are
>>>>>> we reasonably confident that we will not need any further API
>>>>>> changes to pool2 for dbcp2?
>>>>>>>> Great. If there are things I can help with or areas of
>>>>>>>> dicyness [1]
>>>>>>>> in need of extra testing, let me know.
>>>>>>> I don't think any one part is dicer than any other. Having the
>>>>>>> existing
>>>>>>> test suite has really helped.
>>>>>>>
>>>>>>> If I had to pick on something, it would be the improved
>>>>>>> concurrency.
>>>>>>> Since that is the new bit, that is where the current test cases
>>>>>>> may ber
>>>>>>> lacking.
>>>>>> I am fixing [performance] up to work fully with [pool] 2 and to
>>>>>> leverage the new stats reporting.
>>>>>>
>>>>>> One question for the list: is it still possible to release commons
>>>>>> components "manually" to the maven repos - i.e., without using
>>>>>> Nexus
>>>>> No.
>>>>>
>>>>> The only way to the repo is via Nexus staging.
>>>> Does this mean that the instructions on
>>>> http://commons.apache.org/releases/index.html are outdated and do
>>>> not work any more?
>>> Yes, that's what that means, at least for the uploading to mvn repos
>>> bit, and unless we can find a creative way to circumvent nexus,
>>> there appears to be no way to generate the release artifacts
>>> packages locally, inspect them, and keep them on p.a.o for voting
>>> and release. Unless we decide to separate the maven repo publishing
>>> step, which I may be inclined to do for [pool] 2. The steps to get
>>> the real distro (source and binary tars and zips) to the mirrors
>>> should still work, modulo some pom hacking to work around plugin
>>> regressions.
>> Nexus does not prevent any of this; it is a staging repo.
>
> It does block what used to be a simple, controlled process
>
> 0) generate, test and sign artifacts locally
> 1) upload to p.a.o
> 2) vote
> 3) move to release locations
This is much what one does now, where:
1) use maven to deploy to staging repo
> Now you need to count on maven to "deploy" to the staging repo and
> then move things across the network somehow to /dist.
>
> Unless, as you point out below, you make the actual release
> artifacts first and then "publish" to maven central separately.
Not sure I follow that.
> Unfortunately, that ends up requiring two votes, because you can't
> just move stuff into the staging repo (unless there is some way to
> do that, which would be great).
No, it only requires one vote, which is on the artifacts in the staging repo.
>>
>> Note that Maven does not know anything about Nexus; Maven deploys to
>> the staging area which happens to be managed by Nexus.
>>
>> The non-Maven archives can either be deployed with the Maven jars to
>> Nexus, and then the vote held on the combined set of archives,
>> or the non-Maven archives can be deployed to a separate holding area.
>>
>> If using a combined staging area, the non-Maven stuff needs to be
>> copied dist/ (and deleted from the staging area) before the Maven
>> stuff is released.
>> [I had hoped that Nexus could be tweaked to do this automatically but
>> this has not happened]
>>
>> Nexus does not fundamentally change the release process, its main
>> benefit is that it makes it harder to publish Maven artifacts
>> accidentally, as happened a lot of times before it was introduced.
>
> Only once in Commons, IIRC, due to an RM not following the "manual"
> process and running with scissors using the release plugin.
Just done a quick check of 3 projects at random:
http://central.maven.org/maven2/commons-jexl/commons-jexl/
http://central.maven.org/maven2/commons-lang/commons-lang/
http://central.maven.org/maven2/commons-net/commons-net/
Have a look at those directories; I'm pretty sure no-one really voted
on release version "20030307.151331".
Looks like snapshot versions were somehow released as full versions.
It seems unlikely that version 1.0-RC1 was ever intended for release either.
>>
>> Nexus also takes care of maintaining the Maven metadata, and ensuring
>> that the files are created in the correct directory.
>
> Trival and easy to verify as part of the release prep and vote.
This is not a process I would describe as trivial.
> Phil
>>
>>> Phil
>>>> Oliver
>>>>
>>>>>> or the release plugin?
>>>>> Yes.
>>>>>
>>>>> You don't need to use the release plugin.
>>>>> I never have used it, and I've been RM for Net and CP etc.
>>>>>
>>>>> Just need to use "mvn deploy" with the appropriate profile and
>>>>> flags.
>>>>>
>>>>>
>>>>>> Phil
>>>>>>> Mark
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by Phil Steitz <ph...@gmail.com>.
On 6/24/12 12:00 PM, sebb wrote:
> On 24 June 2012 15:41, Phil Steitz <ph...@gmail.com> wrote:
>> On 6/24/12 7:12 AM, Oliver Heger wrote:
>>> Am 24.06.2012 03:05, schrieb sebb:
>>>> On 23 June 2012 23:00, Phil Steitz <ph...@gmail.com> wrote:
>>>>> On 6/17/12 2:20 PM, Mark Thomas wrote:
>>>>>> On 17/06/2012 16:26, Phil Steitz wrote:
>>>>>>> On 6/17/12 1:13 AM, Mark Thomas wrote:
>>>>>>>> On 17/06/2012 08:49, Phil Steitz wrote:
>>>>>>>>> Looks like only the relatively trivial POOL-220 and POOL-217
>>>>>>>>> affect
>>>>>>>>> 2.0.
>>>>>>>> +1
>>>>>>>>
>>>>>>>>> We need to resolve these and do some javadoc and site
>>>>>>>>> cleanup; but unless there are other things we want to get
>>>>>>>>> into 2.0,
>>>>>>>>> I would like to move this toward a release. I will
>>>>>>>>> volunteer to RM
>>>>>>>>> if no one else wants to. Is there anything else we need to do
>>>>>>>>> code-wise to get this ready?
>>>>>>>> I don't think so. I got most things cleaned up before I became
>>>>>>>> distracted (for far longer than I expected) by a Tomcat 7
>>>>>>>> release.
>>>>>>>>
>>>>>>>> The Tomcat 7 release is almost done, so I should be able to
>>>>>>>> spend some
>>>>>>>> time on POOL 2 / DBCP 2 in the coming weeks.
>>>>>> The two open issues for 2.x have been fixed. That leaves one
>>>>>> enhancement, one 1.x specific issue and one issue that doesn't
>>>>>> as yet
>>>>>> have a satisfactory explanation. I think the code is ready for
>>>>>> a 2.0
>>>>>> release. A lot of the supporting material isn't.
>>>>> I will get to work on that. Patches welcome, of course :)
>>>>>
>>>>> I will also start testing with dbcp2 to make sure all is well. Are
>>>>> we reasonably confident that we will not need any further API
>>>>> changes to pool2 for dbcp2?
>>>>>>> Great. If there are things I can help with or areas of
>>>>>>> dicyness [1]
>>>>>>> in need of extra testing, let me know.
>>>>>> I don't think any one part is dicer than any other. Having the
>>>>>> existing
>>>>>> test suite has really helped.
>>>>>>
>>>>>> If I had to pick on something, it would be the improved
>>>>>> concurrency.
>>>>>> Since that is the new bit, that is where the current test cases
>>>>>> may ber
>>>>>> lacking.
>>>>> I am fixing [performance] up to work fully with [pool] 2 and to
>>>>> leverage the new stats reporting.
>>>>>
>>>>> One question for the list: is it still possible to release commons
>>>>> components "manually" to the maven repos - i.e., without using
>>>>> Nexus
>>>> No.
>>>>
>>>> The only way to the repo is via Nexus staging.
>>> Does this mean that the instructions on
>>> http://commons.apache.org/releases/index.html are outdated and do
>>> not work any more?
>> Yes, that's what that means, at least for the uploading to mvn repos
>> bit, and unless we can find a creative way to circumvent nexus,
>> there appears to be no way to generate the release artifacts
>> packages locally, inspect them, and keep them on p.a.o for voting
>> and release. Unless we decide to separate the maven repo publishing
>> step, which I may be inclined to do for [pool] 2. The steps to get
>> the real distro (source and binary tars and zips) to the mirrors
>> should still work, modulo some pom hacking to work around plugin
>> regressions.
> Nexus does not prevent any of this; it is a staging repo.
It does block what used to be a simple, controlled process
0) generate, test and sign artifacts locally
1) upload to p.a.o
2) vote
3) move to release locations
Now you need to count on maven to "deploy" to the staging repo and
then move things across the network somehow to /dist.
Unless, as you point out below, you make the actual release
artifacts first and then "publish" to maven central separately.
Unfortunately, that ends up requiring two votes, because you can't
just move stuff into the staging repo (unless there is some way to
do that, which would be great).
>
> Note that Maven does not know anything about Nexus; Maven deploys to
> the staging area which happens to be managed by Nexus.
>
> The non-Maven archives can either be deployed with the Maven jars to
> Nexus, and then the vote held on the combined set of archives,
> or the non-Maven archives can be deployed to a separate holding area.
>
> If using a combined staging area, the non-Maven stuff needs to be
> copied dist/ (and deleted from the staging area) before the Maven
> stuff is released.
> [I had hoped that Nexus could be tweaked to do this automatically but
> this has not happened]
>
> Nexus does not fundamentally change the release process, its main
> benefit is that it makes it harder to publish Maven artifacts
> accidentally, as happened a lot of times before it was introduced.
Only once in Commons, IIRC, due to an RM not following the "manual"
process and running with scissors using the release plugin.
>
> Nexus also takes care of maintaining the Maven metadata, and ensuring
> that the files are created in the correct directory.
Trival and easy to verify as part of the release prep and vote.
Phil
>
>> Phil
>>> Oliver
>>>
>>>>> or the release plugin?
>>>> Yes.
>>>>
>>>> You don't need to use the release plugin.
>>>> I never have used it, and I've been RM for Net and CP etc.
>>>>
>>>> Just need to use "mvn deploy" with the appropriate profile and
>>>> flags.
>>>>
>>>>
>>>>> Phil
>>>>>> Mark
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by sebb <se...@gmail.com>.
On 24 June 2012 15:41, Phil Steitz <ph...@gmail.com> wrote:
> On 6/24/12 7:12 AM, Oliver Heger wrote:
>> Am 24.06.2012 03:05, schrieb sebb:
>>> On 23 June 2012 23:00, Phil Steitz <ph...@gmail.com> wrote:
>>>> On 6/17/12 2:20 PM, Mark Thomas wrote:
>>>>> On 17/06/2012 16:26, Phil Steitz wrote:
>>>>>> On 6/17/12 1:13 AM, Mark Thomas wrote:
>>>>>>> On 17/06/2012 08:49, Phil Steitz wrote:
>>>>>>>> Looks like only the relatively trivial POOL-220 and POOL-217
>>>>>>>> affect
>>>>>>>> 2.0.
>>>>>>> +1
>>>>>>>
>>>>>>>> We need to resolve these and do some javadoc and site
>>>>>>>> cleanup; but unless there are other things we want to get
>>>>>>>> into 2.0,
>>>>>>>> I would like to move this toward a release. I will
>>>>>>>> volunteer to RM
>>>>>>>> if no one else wants to. Is there anything else we need to do
>>>>>>>> code-wise to get this ready?
>>>>>>> I don't think so. I got most things cleaned up before I became
>>>>>>> distracted (for far longer than I expected) by a Tomcat 7
>>>>>>> release.
>>>>>>>
>>>>>>> The Tomcat 7 release is almost done, so I should be able to
>>>>>>> spend some
>>>>>>> time on POOL 2 / DBCP 2 in the coming weeks.
>>>>> The two open issues for 2.x have been fixed. That leaves one
>>>>> enhancement, one 1.x specific issue and one issue that doesn't
>>>>> as yet
>>>>> have a satisfactory explanation. I think the code is ready for
>>>>> a 2.0
>>>>> release. A lot of the supporting material isn't.
>>>>
>>>> I will get to work on that. Patches welcome, of course :)
>>>>
>>>> I will also start testing with dbcp2 to make sure all is well. Are
>>>> we reasonably confident that we will not need any further API
>>>> changes to pool2 for dbcp2?
>>>>>
>>>>>> Great. If there are things I can help with or areas of
>>>>>> dicyness [1]
>>>>>> in need of extra testing, let me know.
>>>>> I don't think any one part is dicer than any other. Having the
>>>>> existing
>>>>> test suite has really helped.
>>>>>
>>>>> If I had to pick on something, it would be the improved
>>>>> concurrency.
>>>>> Since that is the new bit, that is where the current test cases
>>>>> may ber
>>>>> lacking.
>>>>
>>>> I am fixing [performance] up to work fully with [pool] 2 and to
>>>> leverage the new stats reporting.
>>>>
>>>> One question for the list: is it still possible to release commons
>>>> components "manually" to the maven repos - i.e., without using
>>>> Nexus
>>>
>>> No.
>>>
>>> The only way to the repo is via Nexus staging.
>>
>> Does this mean that the instructions on
>> http://commons.apache.org/releases/index.html are outdated and do
>> not work any more?
>
> Yes, that's what that means, at least for the uploading to mvn repos
> bit, and unless we can find a creative way to circumvent nexus,
> there appears to be no way to generate the release artifacts
> packages locally, inspect them, and keep them on p.a.o for voting
> and release. Unless we decide to separate the maven repo publishing
> step, which I may be inclined to do for [pool] 2. The steps to get
> the real distro (source and binary tars and zips) to the mirrors
> should still work, modulo some pom hacking to work around plugin
> regressions.
Nexus does not prevent any of this; it is a staging repo.
Note that Maven does not know anything about Nexus; Maven deploys to
the staging area which happens to be managed by Nexus.
The non-Maven archives can either be deployed with the Maven jars to
Nexus, and then the vote held on the combined set of archives,
or the non-Maven archives can be deployed to a separate holding area.
If using a combined staging area, the non-Maven stuff needs to be
copied dist/ (and deleted from the staging area) before the Maven
stuff is released.
[I had hoped that Nexus could be tweaked to do this automatically but
this has not happened]
Nexus does not fundamentally change the release process, its main
benefit is that it makes it harder to publish Maven artifacts
accidentally, as happened a lot of times before it was introduced.
Nexus also takes care of maintaining the Maven metadata, and ensuring
that the files are created in the correct directory.
> Phil
>>
>> Oliver
>>
>>>
>>>> or the release plugin?
>>>
>>> Yes.
>>>
>>> You don't need to use the release plugin.
>>> I never have used it, and I've been RM for Net and CP etc.
>>>
>>> Just need to use "mvn deploy" with the appropriate profile and
>>> flags.
>>>
>>>
>>>>
>>>> Phil
>>>>>
>>>>> Mark
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by Phil Steitz <ph...@gmail.com>.
On 6/24/12 7:12 AM, Oliver Heger wrote:
> Am 24.06.2012 03:05, schrieb sebb:
>> On 23 June 2012 23:00, Phil Steitz <ph...@gmail.com> wrote:
>>> On 6/17/12 2:20 PM, Mark Thomas wrote:
>>>> On 17/06/2012 16:26, Phil Steitz wrote:
>>>>> On 6/17/12 1:13 AM, Mark Thomas wrote:
>>>>>> On 17/06/2012 08:49, Phil Steitz wrote:
>>>>>>> Looks like only the relatively trivial POOL-220 and POOL-217
>>>>>>> affect
>>>>>>> 2.0.
>>>>>> +1
>>>>>>
>>>>>>> We need to resolve these and do some javadoc and site
>>>>>>> cleanup; but unless there are other things we want to get
>>>>>>> into 2.0,
>>>>>>> I would like to move this toward a release. I will
>>>>>>> volunteer to RM
>>>>>>> if no one else wants to. Is there anything else we need to do
>>>>>>> code-wise to get this ready?
>>>>>> I don't think so. I got most things cleaned up before I became
>>>>>> distracted (for far longer than I expected) by a Tomcat 7
>>>>>> release.
>>>>>>
>>>>>> The Tomcat 7 release is almost done, so I should be able to
>>>>>> spend some
>>>>>> time on POOL 2 / DBCP 2 in the coming weeks.
>>>> The two open issues for 2.x have been fixed. That leaves one
>>>> enhancement, one 1.x specific issue and one issue that doesn't
>>>> as yet
>>>> have a satisfactory explanation. I think the code is ready for
>>>> a 2.0
>>>> release. A lot of the supporting material isn't.
>>>
>>> I will get to work on that. Patches welcome, of course :)
>>>
>>> I will also start testing with dbcp2 to make sure all is well. Are
>>> we reasonably confident that we will not need any further API
>>> changes to pool2 for dbcp2?
>>>>
>>>>> Great. If there are things I can help with or areas of
>>>>> dicyness [1]
>>>>> in need of extra testing, let me know.
>>>> I don't think any one part is dicer than any other. Having the
>>>> existing
>>>> test suite has really helped.
>>>>
>>>> If I had to pick on something, it would be the improved
>>>> concurrency.
>>>> Since that is the new bit, that is where the current test cases
>>>> may ber
>>>> lacking.
>>>
>>> I am fixing [performance] up to work fully with [pool] 2 and to
>>> leverage the new stats reporting.
>>>
>>> One question for the list: is it still possible to release commons
>>> components "manually" to the maven repos - i.e., without using
>>> Nexus
>>
>> No.
>>
>> The only way to the repo is via Nexus staging.
>
> Does this mean that the instructions on
> http://commons.apache.org/releases/index.html are outdated and do
> not work any more?
Yes, that's what that means, at least for the uploading to mvn repos
bit, and unless we can find a creative way to circumvent nexus,
there appears to be no way to generate the release artifacts
packages locally, inspect them, and keep them on p.a.o for voting
and release. Unless we decide to separate the maven repo publishing
step, which I may be inclined to do for [pool] 2. The steps to get
the real distro (source and binary tars and zips) to the mirrors
should still work, modulo some pom hacking to work around plugin
regressions.
Phil
>
> Oliver
>
>>
>>> or the release plugin?
>>
>> Yes.
>>
>> You don't need to use the release plugin.
>> I never have used it, and I've been RM for Net and CP etc.
>>
>> Just need to use "mvn deploy" with the appropriate profile and
>> flags.
>>
>>
>>>
>>> Phil
>>>>
>>>> Mark
>>>>
>>>> ---------------------------------------------------------------------
>>>>
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>>
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by Oliver Heger <ol...@oliver-heger.de>.
Am 24.06.2012 03:05, schrieb sebb:
> On 23 June 2012 23:00, Phil Steitz <ph...@gmail.com> wrote:
>> On 6/17/12 2:20 PM, Mark Thomas wrote:
>>> On 17/06/2012 16:26, Phil Steitz wrote:
>>>> On 6/17/12 1:13 AM, Mark Thomas wrote:
>>>>> On 17/06/2012 08:49, Phil Steitz wrote:
>>>>>> Looks like only the relatively trivial POOL-220 and POOL-217 affect
>>>>>> 2.0.
>>>>> +1
>>>>>
>>>>>> We need to resolve these and do some javadoc and site
>>>>>> cleanup; but unless there are other things we want to get into 2.0,
>>>>>> I would like to move this toward a release. I will volunteer to RM
>>>>>> if no one else wants to. Is there anything else we need to do
>>>>>> code-wise to get this ready?
>>>>> I don't think so. I got most things cleaned up before I became
>>>>> distracted (for far longer than I expected) by a Tomcat 7 release.
>>>>>
>>>>> The Tomcat 7 release is almost done, so I should be able to spend some
>>>>> time on POOL 2 / DBCP 2 in the coming weeks.
>>> The two open issues for 2.x have been fixed. That leaves one
>>> enhancement, one 1.x specific issue and one issue that doesn't as yet
>>> have a satisfactory explanation. I think the code is ready for a 2.0
>>> release. A lot of the supporting material isn't.
>>
>> I will get to work on that. Patches welcome, of course :)
>>
>> I will also start testing with dbcp2 to make sure all is well. Are
>> we reasonably confident that we will not need any further API
>> changes to pool2 for dbcp2?
>>>
>>>> Great. If there are things I can help with or areas of dicyness [1]
>>>> in need of extra testing, let me know.
>>> I don't think any one part is dicer than any other. Having the existing
>>> test suite has really helped.
>>>
>>> If I had to pick on something, it would be the improved concurrency.
>>> Since that is the new bit, that is where the current test cases may ber
>>> lacking.
>>
>> I am fixing [performance] up to work fully with [pool] 2 and to
>> leverage the new stats reporting.
>>
>> One question for the list: is it still possible to release commons
>> components "manually" to the maven repos - i.e., without using Nexus
>
> No.
>
> The only way to the repo is via Nexus staging.
Does this mean that the instructions on
http://commons.apache.org/releases/index.html are outdated and do not
work any more?
Oliver
>
>> or the release plugin?
>
> Yes.
>
> You don't need to use the release plugin.
> I never have used it, and I've been RM for Net and CP etc.
>
> Just need to use "mvn deploy" with the appropriate profile and flags.
>
>
>>
>> Phil
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by sebb <se...@gmail.com>.
On 23 June 2012 23:00, Phil Steitz <ph...@gmail.com> wrote:
> On 6/17/12 2:20 PM, Mark Thomas wrote:
>> On 17/06/2012 16:26, Phil Steitz wrote:
>>> On 6/17/12 1:13 AM, Mark Thomas wrote:
>>>> On 17/06/2012 08:49, Phil Steitz wrote:
>>>>> Looks like only the relatively trivial POOL-220 and POOL-217 affect
>>>>> 2.0.
>>>> +1
>>>>
>>>>> We need to resolve these and do some javadoc and site
>>>>> cleanup; but unless there are other things we want to get into 2.0,
>>>>> I would like to move this toward a release. I will volunteer to RM
>>>>> if no one else wants to. Is there anything else we need to do
>>>>> code-wise to get this ready?
>>>> I don't think so. I got most things cleaned up before I became
>>>> distracted (for far longer than I expected) by a Tomcat 7 release.
>>>>
>>>> The Tomcat 7 release is almost done, so I should be able to spend some
>>>> time on POOL 2 / DBCP 2 in the coming weeks.
>> The two open issues for 2.x have been fixed. That leaves one
>> enhancement, one 1.x specific issue and one issue that doesn't as yet
>> have a satisfactory explanation. I think the code is ready for a 2.0
>> release. A lot of the supporting material isn't.
>
> I will get to work on that. Patches welcome, of course :)
>
> I will also start testing with dbcp2 to make sure all is well. Are
> we reasonably confident that we will not need any further API
> changes to pool2 for dbcp2?
>>
>>> Great. If there are things I can help with or areas of dicyness [1]
>>> in need of extra testing, let me know.
>> I don't think any one part is dicer than any other. Having the existing
>> test suite has really helped.
>>
>> If I had to pick on something, it would be the improved concurrency.
>> Since that is the new bit, that is where the current test cases may ber
>> lacking.
>
> I am fixing [performance] up to work fully with [pool] 2 and to
> leverage the new stats reporting.
>
> One question for the list: is it still possible to release commons
> components "manually" to the maven repos - i.e., without using Nexus
No.
The only way to the repo is via Nexus staging.
> or the release plugin?
Yes.
You don't need to use the release plugin.
I never have used it, and I've been RM for Net and CP etc.
Just need to use "mvn deploy" with the appropriate profile and flags.
>
> Phil
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by Phil Steitz <ph...@gmail.com>.
On 6/17/12 2:20 PM, Mark Thomas wrote:
> On 17/06/2012 16:26, Phil Steitz wrote:
>> On 6/17/12 1:13 AM, Mark Thomas wrote:
>>> On 17/06/2012 08:49, Phil Steitz wrote:
>>>> Looks like only the relatively trivial POOL-220 and POOL-217 affect
>>>> 2.0.
>>> +1
>>>
>>>> We need to resolve these and do some javadoc and site
>>>> cleanup; but unless there are other things we want to get into 2.0,
>>>> I would like to move this toward a release. I will volunteer to RM
>>>> if no one else wants to. Is there anything else we need to do
>>>> code-wise to get this ready?
>>> I don't think so. I got most things cleaned up before I became
>>> distracted (for far longer than I expected) by a Tomcat 7 release.
>>>
>>> The Tomcat 7 release is almost done, so I should be able to spend some
>>> time on POOL 2 / DBCP 2 in the coming weeks.
> The two open issues for 2.x have been fixed. That leaves one
> enhancement, one 1.x specific issue and one issue that doesn't as yet
> have a satisfactory explanation. I think the code is ready for a 2.0
> release. A lot of the supporting material isn't.
I will get to work on that. Patches welcome, of course :)
I will also start testing with dbcp2 to make sure all is well. Are
we reasonably confident that we will not need any further API
changes to pool2 for dbcp2?
>
>> Great. If there are things I can help with or areas of dicyness [1]
>> in need of extra testing, let me know.
> I don't think any one part is dicer than any other. Having the existing
> test suite has really helped.
>
> If I had to pick on something, it would be the improved concurrency.
> Since that is the new bit, that is where the current test cases may ber
> lacking.
I am fixing [performance] up to work fully with [pool] 2 and to
leverage the new stats reporting.
One question for the list: is it still possible to release commons
components "manually" to the maven repos - i.e., without using Nexus
or the release plugin?
Phil
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by Mark Thomas <ma...@apache.org>.
On 17/06/2012 16:26, Phil Steitz wrote:
> On 6/17/12 1:13 AM, Mark Thomas wrote:
>> On 17/06/2012 08:49, Phil Steitz wrote:
>>> Looks like only the relatively trivial POOL-220 and POOL-217 affect
>>> 2.0.
>> +1
>>
>>> We need to resolve these and do some javadoc and site
>>> cleanup; but unless there are other things we want to get into 2.0,
>>> I would like to move this toward a release. I will volunteer to RM
>>> if no one else wants to. Is there anything else we need to do
>>> code-wise to get this ready?
>> I don't think so. I got most things cleaned up before I became
>> distracted (for far longer than I expected) by a Tomcat 7 release.
>>
>> The Tomcat 7 release is almost done, so I should be able to spend some
>> time on POOL 2 / DBCP 2 in the coming weeks.
The two open issues for 2.x have been fixed. That leaves one
enhancement, one 1.x specific issue and one issue that doesn't as yet
have a satisfactory explanation. I think the code is ready for a 2.0
release. A lot of the supporting material isn't.
> Great. If there are things I can help with or areas of dicyness [1]
> in need of extra testing, let me know.
I don't think any one part is dicer than any other. Having the existing
test suite has really helped.
If I had to pick on something, it would be the improved concurrency.
Since that is the new bit, that is where the current test cases may ber
lacking.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by Phil Steitz <ph...@gmail.com>.
On 6/17/12 1:13 AM, Mark Thomas wrote:
> On 17/06/2012 08:49, Phil Steitz wrote:
>> Looks like only the relatively trivial POOL-220 and POOL-217 affect
>> 2.0.
> +1
>
>> We need to resolve these and do some javadoc and site
>> cleanup; but unless there are other things we want to get into 2.0,
>> I would like to move this toward a release. I will volunteer to RM
>> if no one else wants to. Is there anything else we need to do
>> code-wise to get this ready?
> I don't think so. I got most things cleaned up before I became
> distracted (for far longer than I expected) by a Tomcat 7 release.
>
> The Tomcat 7 release is almost done, so I should be able to spend some
> time on POOL 2 / DBCP 2 in the coming weeks.
Great. If there are things I can help with or areas of dicyness [1]
in need of extra testing, let me know.
>
>> Phil
>>
>> P.S.: I seem to have lost my commons JIRA karma (can't edit
>> issues). Can someone restore that, please?
> Done. Not I granted you the admin role on the commons projects rather
> than adding you to the commons group.
Thanks!
>
> Is Phil at <your surname> dot com also you? If so I can merge it with
> your more frequently used user.
Yes, that should be me from a much earlier time.
Thanks again.
Phil
[1] I am theoretically convinced it will never result in per key max
exceeded, but I am still a little worried about how calculatedeficit
works in GKOP. I will be banging that a little to see what happens
under high concurrent load with minIdle set.
>
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] 2.0 release
Posted by Mark Thomas <ma...@apache.org>.
On 17/06/2012 08:49, Phil Steitz wrote:
> Looks like only the relatively trivial POOL-220 and POOL-217 affect
> 2.0.
+1
> We need to resolve these and do some javadoc and site
> cleanup; but unless there are other things we want to get into 2.0,
> I would like to move this toward a release. I will volunteer to RM
> if no one else wants to. Is there anything else we need to do
> code-wise to get this ready?
I don't think so. I got most things cleaned up before I became
distracted (for far longer than I expected) by a Tomcat 7 release.
The Tomcat 7 release is almost done, so I should be able to spend some
time on POOL 2 / DBCP 2 in the coming weeks.
> Phil
>
> P.S.: I seem to have lost my commons JIRA karma (can't edit
> issues). Can someone restore that, please?
Done. Not I granted you the admin role on the commons projects rather
than adding you to the commons group.
Is Phil at <your surname> dot com also you? If so I can merge it with
your more frequently used user.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org