Are you saying the artifacts are _wrong_ or you just don't like the timestamp'd file name? Usually the timestamp'd name indicates the file came from a remote repo, which could happen depending on various settings and if it's newer on the remote.
-----Original Message----- From: Markku Saarela [mailto:[EMAIL PROTECTED] Sent: Friday, April 25, 2008 6:04 AM To: Maven Users List Subject: Re: jars appear timestamped in wars and zips since 2.0.9 Hi, While debugging 2.1-alpha-1 war plugin in method ArtifactsPackagingTask.performPackaging( WarPackagingContext context ) DefaultArtifact class instance has right version number and also method getArtifactFinalName( context, artifact ); returns right name -SNAPSHOT also. But when removing all breakpoints and resuming execution all the rest snapshot artifacts has wrong filename in lib directory - markku Markku Saarela wrote: > Hi, > > This start to happen at least we use Maven 2.0.8 version and still > exists in 2.0.9. Tested with war plugin versions 2.0.2 and 2.1-alpha-1 > Here is snipped from > [DEBUG] Adding managed dependencies for <artifactId> > [DEBUG]net.sourceforge.jivalo.fw:jivalo-fw-common:jar:1.5-beta-3-SNAPSHOT > [DEBUG] jivalo-fw-client: resolved to version > 1.5-beta-3-20080415.204821-1 from repository jivalo-snapshot > > Classpath is correct for compiling (uses -SNAPSHOT version and not > timestamped one) and manifest files in jars. > > Maven decides to use remote repositories constantly allmost every > SNAPSHOT versions, not for all. > > Reason seems to be lastUpdated timestamp in artifacts local repository > -SNAPSHOT directory maven-metadata-local.xml file. It is not updated > to newer than remote repository's timestamp at that time than new > version is retrieved from remote repository.. > > Best workaround i found is: > set snapshot versions to provided scope and use dependency plugins > copy-dependencies goal. > > - markku > > [EMAIL PROTECTED] wrote: >> Hi, >> In Maven 2.0.8 I built my war with maven-war-plugin:2.1-alpha-1 and >> my zip with maven-assembly-plugin:2.2-beta-2 >> >> The war/zip contained dependent jars as >> "jarname-version-SNAPSHOT.jar" when the depend jars were located in >> the localrepository. >> The war/zip contained dependent jars as >> "jarname-version-timestamp.jar" when the depend jars were located in >> the central (company) repository and first need to be downloaded. >> >> The difference was in the mavenmetadata-local.xml, where a >> "<localCopy>true</localCopy> entry exists: >> >> <?xml version="1.0" encoding="UTF-8" ?> <metadata> >> ... >> <versioning> >> <snapshot> >> <localCopy>true</localCopy> </snapshot> >> ... >> </versioning> >> </metadata> >> >> Now, In Maven 2.0.9 I still built my war with >> maven-war-plugin:2.1-alpha-1 and my zip with >> maven-assembly-plugin:2.2-beta-2 >> >> But now, the mavenmetadata-local.xml file doesn´t contain a >> "<localCopy>true</localCopy> entry anymore - even if I paste one, it >> gets deleted during the build ! >> This results in always getting wars/zips containing dependent jars as >> "jarname-version-timestamp.jar". >> >> And that´s not very nice, because in the MANIFEST.MF of same jars the >> ""jarname-version-SNAPSHOT.jar" is mentioned, which doesn´t match the >> content of the war/zip, >> Resulting in "NoClassDefFoundError" and so on, caused by an invalid >> classpath.... >> >> The funny point about that story is that with the maven-ear-plugin >> the jars appear as ""jarname-version-SNAPSHOT.jar" in the generated >> *.ear. >> >> => Any idea how to fix that for the war and zip? Why is there a >> difference in handling jars between the war, ear and assembly >> plugins? Isn´t it always the same? >> >> >> >> Thanx, Torsten >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
