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]
