commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [pool] 2.0 release
Date Sun, 24 Jun 2012 19:00:50 GMT
On 24 June 2012 15:41, Phil Steitz <phil.steitz@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.steitz@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


Mime
View raw message