On 24 June 2012 15:41, Phil Steitz <[email protected]> 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 <[email protected]> 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: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> --------------------------------------------------------------------- >>> >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
