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)
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.
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]
