On 24 June 2012 20:41, Phil Steitz <phil.ste...@gmail.com> wrote: > 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
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-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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
