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
