On 6/24/12 12:00 PM, sebb wrote: > On 24 June 2012 15:41, Phil Steitz <phil.ste...@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 <phil.ste...@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-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
