They are wrong because dependency is for -SNAPSHOT versions and
manifests in jars has classpath to these -SNAPSHOT versions and
therefore classes from these wrongly named jar in war lib directory
can't be found. War plugin should get these new timestamped jars from
local repo and rename them correctly to -SNAPSHOT as ear plugin does
- markku
.
Brian E. Fox wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
