Hi Eric,
yes, this makes sense.
Actually, we also want to automate this process with Hudson, but I tried the
steps manually first.
Do you also take advantage of JarDiffs when using SNAPSHOTs for deployment?
In this case you have to keep the JARS of old versions available on the
target machine.
But because the JARS are always named myjar-myversion-SNAPSHOT.jar you have
to keep them
in separate directories or rename them. In both cases you have to
postprocess the version.xml
to account for that.
Or how do you handle this?
Thanks,
Holger
Eric Malotaux wrote:
>
> My work-around is similar: I have removed the locally built SNAPSHOT
> artifacts from my local repository. Furthermore I have separated the
> artifacts to include in the JNLP from the maven modules that creates the
> JNLP into other modules, actually under its own {trunk,tags,branches}. The
> Hudson job that builds the JNLP has its own private local repository, so
> that the artifacts are downloaded from the remote Nexus repository where
> they have been deployed by another Hudson job. Does this sound clear?
>
> In this setup the SNAPSHOT strings are always expanded in the <version-id>
> elements in the version.xml in the JNLP. And the JWS caching works
> perfect!
> New versions of jar-files are always downloaded and jar-files that have
> not
> changed (Spring, Hibernate, actually by far the most) are not downloaded
> again!
>
> 2010/3/30 Holger Brands <[email protected]>
>
>>
>> Hi,
>>
>> I'm having the same problem.
>> Further analysis shows that the problem is related to the contents of the
>> local repo.
>> If it already contains a snapshot artifact having a metadata entry (in
>> maven-metadata-local.xml)
>> with localCopy=true, then the SNAPSHOT version is not expanded in
>> "version.xml" or the jnlp file.
>> If there is no snapshot artifact in the local repo or the metadata entry
>> doesn't contain
>> the localCopy=true statement, the version is correctly expanded.
>>
>> I think the localCopy=true metadata is created in your local repo, if you
>> deploy a new snapshot
>> to a remote snapshot repo.
>>
>> So as a workaround, after deploying a new snapshot, you've to cleanup the
>> snapshots in your local repo first.
>>
>> Is there a recommended way to purge snapshots from the local repo?
>>
>> Or is this a bug in the webstart plugin that could be fixed soon?
>>
>> Thanks,
>> Holger
>>
>>
>>
>> Eric Malotaux wrote:
>> >
>> > Hi,
>> >
>> > When I include SNAPSHOT dependencies in my jnlp file with the
>> > jnlp-download-servlet mojo, the SNAPSHOT version is not expanded into a
>> > timestamp plus version string in the "version.xml" file. As a result
>> JWS
>> > will not download new versions of those files, because the version-id
>> > stays
>> > the same.
>> >
>> > How do I make the mojo expand the SNAPSHOT keyword?
>> >
>> > Thanks,
>> >
>> > --
>> > Eric Jan Malotaux
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/webstart-maven-plugin-tp27959834p28081357.html
>> Sent from the mojo - user mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
> --
> Eric Jan Malotaux
>
>
--
View this message in context:
http://old.nabble.com/webstart-maven-plugin-tp27959834p28092141.html
Sent from the mojo - user mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
