maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Tran <>
Subject Re: [VOTE] Apache Maven 3.0.4 (take 2)
Date Sat, 03 Dec 2011 20:10:40 GMT
here is sample pom.xml to reproduce the issue.  3.0.3 generate the
correct lib dir, and script, but not 3.0.4

<project xmlns=""











On Sat, Dec 3, 2011 at 8:42 AM, Brian Fox <> wrote:
> The RCs were started for a very specific reason, to improve the
> quality of our releases. Just breezing through this thread, there are
> clearly issues with memory and some other stuff here that may be
> bigger than we understand in this small testing surface. An RC build
> will get more eyes and either confirm these aren't a big deal, or they
> are.
> Reminder of where we were with 2.0.7, 2.0.8 and why we do RCs:
> I'm -1 on a release without some RCs.
> On Thu, Dec 1, 2011 at 3:17 PM, John Casey <> wrote:
>> On 12/1/11 10:27 AM, Olivier Lamy wrote:
>>> 2011/12/1 Jörg Schaible<>:
>>>> Benjamin Bentmann wrote:
>>>>> Olivier Lamy wrote:
>>>>>> I'd like to release Apache Maven 3.0.4 (take 2).
>>>>>> [...]
>>>>>> Note the difference with first vote is an upgrade of aether to 1.13.1
>>>>> What about the memory issue that Jörg brought up? Shouldn't we at least
>>>>> understand the cause and potential impact on other users before
>>>>> continuing the release?
>>>> Continue, I'll report later, but it seems that there's no regression in
>>>> 304
>>>> vs 303.
>>> Thanks!
>>> @Benjamin: I tend to say we must release it (maybe the famous "early
>>> and often' :-) ).
>> Early-and-often is great, but it's not an excuse to be lax on quality
>> standards. Hudson had some famously horrible releases early on, and I
>> suspect they had to do with sacrificing concerns about quality on the altar
>> of early-and-often.
>> An RC would take less than a week more if the code really is ready to go. If
>> it's not, then we don't want to release it, do we?
>>> My goal is to provide a release point (stable tagged build) to get
>>> feedbacks.
>>> Trying to reach/wait the "perfect release" without those feedbacks is
>>> IMHO impossible.
>> Actually it's not; the feedback comes by way of RCs. This is why it's so
>> important to do RCs for Maven core. Maybe we can skip the RC process on
>> plugins (I tend to think a single, quick RC is still a good idea there), but
>> the core is far, far more complex. Even with a huge IT set we cannot hope to
>> cover all use cases there, so it's simply not enough.
>> If Jörg's issue doesn't pop up in this staged release, then I'd say let's
>> just learn that lesson for next time. It takes a little longer using RCs,
>> but it's the ONLY way we've been able to produce releases that weren't
>> riddled with regressions in the past. Even with a strong IT suite, it's
>> still good practice.
>> As an aside, we might as well call this staging of 3.0.4 a RC and discuss it
>> here as if it was. The main difference is procedural IMO, in that this is a
>> [VOTE] thread, not a [DISCUSS] thread about whether the staged RC is ready
>> to go. IMO that's an important distinction, since the 72h time limit is
>> lurking nearby, but we'd still want to time-box the review of any RC
>>> The previous "issue" for ngnix users was blocker as some oss forge use
>>> it. So I cancel it and restart one (and thanks for the fast aether
>>> change).
>>> But for such memory issue at least users can change MAVEN_OPTS.
>>> My email [1] to Jörg describe various things to test on his private
>>> company build (I hope he will have time to provide such feedbacks with
>>> a stable maven build)
>>>> Cheers,
>>>> Jörg
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>> --
>> John Casey
>> Developer, PMC Chair - Apache Maven (
>> Blog:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message