2010/3/31 Holger Brands <[email protected]>
>
> Hi Eric,
>
> yes, this makes sense.
> Actually, we also want to automate this process with Hudson, but I tried
> the
> steps manually first.
>
Of course!
>
> Do you also take advantage of JarDiffs when using SNAPSHOTs for deployment?
>
No I didn't. In our case the download is fast enough when just using
versions.
> 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.
>
I wouldn't go into that much trouble just to win another second or so. But
of course if download speed is essential for your application it may become
worth it.
I have just once tried pack200, but gave up when it did not work right away.
> 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
>
>
>
--
Eric Jan Malotaux
