You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by to...@gi-de.com on 2008/04/24 17:21:42 UTC
jars appear timestamped in wars and zips since 2.0.9
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
Re: jars appear timestamped in wars and zips since 2.0.9
Posted by Markku Saarela <ma...@kolumbus.fi>.
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
torsten.reinhard@gi-de.com 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: jars appear timestamped in wars and zips since 2.0.9
Posted by Markku Saarela <ma...@iki.fi>.
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:markku.saarela@iki.fi]
> 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
>>
>> torsten.reinhard@gi-de.com 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: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: jars appear timestamped in wars and zips since 2.0.9
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
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:markku.saarela@iki.fi]
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
>
> torsten.reinhard@gi-de.com 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: jars appear timestamped in wars and zips since 2.0.9
Posted by Markku Saarela <ma...@iki.fi>.
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
>
> torsten.reinhard@gi-de.com 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: jars appear timestamped in wars and zips since 2.0.9
Posted by Markku Saarela <ma...@iki.fi>.
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
torsten.reinhard@gi-de.com 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org