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
