maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Tran <dant...@gmail.com>
Subject Re: [VOTE] Apache Maven 3.0.4 (take 2)
Date Sun, 04 Dec 2011 01:09:08 GMT
Thanks for looking into this issue.  consider it is a blocking
regression since there is no work around for me to use 3.0.4

\-D

On Sat, Dec 3, 2011 at 1:47 PM, Olivier Lamy <olamy@apache.org> wrote:
> Thanks!
> It looks an erroneous file is picked when it has been download from a
> remote repo and when it's reinstall locally (use case of appassembler
> which reinstall file locally)
>
> investigating...
>
> 2011/12/3 Dan Tran <dantran@gmail.com>:
>> 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="http://maven.apache.org/POM/4.0.0"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/maven-v4_0_0.xsd">
>>
>>  <modelVersion>4.0.0</modelVersion>
>>
>>
>>
>>  <groupId>my.groupId</groupId>
>>  <artifactId>myArtifactId</artifactId>
>>  <version>1-SNAPSHOT</version>
>>
>>  <packaging>jar</packaging>
>>
>>  <dependencies>
>>
>>    <dependency>
>>      <groupId>commons-cli</groupId>
>>      <artifactId>commons-cli</artifactId>
>>      <version>1.3-SNAPSHOT</version>
>>    </dependency>
>>
>>  </dependencies>
>>
>>  <build>
>>
>>    <plugins>
>>
>>      <plugin>
>>        <groupId>org.codehaus.mojo</groupId>
>>        <artifactId>appassembler-maven-plugin</artifactId>
>>        <version>1.1.1</version>
>>        <executions>
>>          <execution>
>>            <id>generate-setup-scripts</id>
>>            <phase>prepare-package</phase>
>>            <goals>
>>              <goal>assemble</goal>
>>            </goals>
>>            <configuration>
>>              <repositoryLayout>flat</repositoryLayout>
>>              <generateRepository>true</generateRepository>
>>              <repositoryName>lib</repositoryName>
>>              <programs>
>>                <program>
>>                  <mainClass>fake.Main</mainClass>
>>                  <name>setup</name>
>>                </program>
>>              </programs>
>>              <platforms>
>>                <platform>unix</platform>
>>              </platforms>
>>            </configuration>
>>          </execution>
>>        </executions>
>>      </plugin>
>>    </plugins>
>>  </build>
>>
>>
>> </project>
>>
>>
>> On Sat, Dec 3, 2011 at 8:42 AM, Brian Fox <brianf@infinity.nu> 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:
>>> http://www.sonatype.com/people/2008/04/quality-is-not-accidental/
>>>
>>> I'm -1 on a release without some RCs.
>>>
>>>
>>>
>>> On Thu, Dec 1, 2011 at 3:17 PM, John Casey <jdcasey@commonjava.org> wrote:
>>>> On 12/1/11 10:27 AM, Olivier Lamy wrote:
>>>>>
>>>>> 2011/12/1 Jörg Schaible<joerg.schaible@scalaris.com>:
>>>>>>
>>>>>> 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: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> John Casey
>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org)
>>>> Blog: http://www.johnofalltrades.name/
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message