Thanks to you for the test sample. I will cancel the vote and investigate more on monday (as not sure to have enough time on this sunday) My first impression is a side effect of this fix: https://issues.sonatype.org/browse/AETHER-91. But need more investigation.
-- Olivier 2011/12/4 Dan Tran <dant...@gmail.com>: > 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 <ol...@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 <dant...@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 <bri...@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 <jdca...@commonjava.org> wrote: >>>>> On 12/1/11 10:27 AM, Olivier Lamy wrote: >>>>>> >>>>>> 2011/12/1 Jörg Schaible<joerg.schai...@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-unsubscr...@maven.apache.org >>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> John Casey >>>>> Developer, PMC Chair - Apache Maven (http://maven.apache.org) >>>>> Blog: http://www.johnofalltrades.name/ >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> >> >> -- >> Olivier Lamy >> Talend: http://coders.talend.com >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
