Hi Jerome, Thanks for the feedback. I wouldn't say that the plugin already does too much. For me, it doesn't quite do enough. I agree with you that there might not be many projects that 'need' this functionality but I know that mine certainly does. Not just from a technical point of view, but also because I have to justify to my boss that Maven can give us everything that we used to have with our previous Ant build.
I know you're busy and I'm happy to do the work myself. I still haven't given much thought to the solution but I'm leaning towards the idea that the webstart plugin should not be responsible for collating the jars to be bundled for deployment. Or if it is still responsible, then the current mechanism should be modified so that it doesn't require the jars to be declared as project dependencies because of the limitation of only being able to declare a single version of a given artifact. You were suggesting creating a new mojo that can add older versions to an existing bundle. Instead of going down that route, how about creating a new mojo that is intended for use in projects using JnlpDownloadServlet. For example, it would have the following characteristics: * Can be used within a war project. * Does not produce its own artifact, but processes jars and stores them in an output directory prior to the war being packaged, e.g. my-project/target/my-project-1.0.war/webstart/ * Optionally generates a version.xml file. * Enables multiple versions of the same artifact to be bundled. Let me know what you think. Cheers, Kevin On Thu, 2007-05-17 at 09:10 +0200, Jerome Lacoste wrote: > On 5/15/07, Kevin Stembridge <[EMAIL PROTECTED]> wrote: > > > > Hi all (and Jerome in particular), > > I recently submitted a patch to enable the addition of a version attribute > > in each jar resource element declared in the generated JNLP file. > > I needed this to enable incremental updates when using the > > JnlpDownloadServlet. I've been getting a better understanding of how these > > incremental updates work and it looks like a bit more work will be required > > on the plugin. > > > > First of all, the version number needs to be stripped from the file name > > used in the href attribute when a version attribute is provided. > > > > Second, we need to be able to bundle multiple versions of the same > > dependency in the zip artifact produced by the plugin. This is to enable a > > jardiff to be generated for the differences between the version of the jar > > on the client and the latest version declared in the JNLP. > > > > I haven't given this much thought yet, but the first thing that came to > > mind was that the way a jnlp project currently declares dependencies won't > > work. Maybe we could use the dependency plugin to collate the required jar > > files into a working directory from which they can then be signed and > > compressed. > > > > Any thoughts? > > Kevin, > > I've given even less thoughts to the problem than you :) In particular > because I don't use the incremental updates feature of the > JnlpDownload servlet. > > My first impression is that this is a somewhat complex feature and I > am not sure how many users need it. > > Second I already think that the jnlp plugin does a little bit too > much. I don't want it to become the plugin that does everything in a > bad way. > > So I am not sure how bundling old releases should happen. Should a > mojo pick all old releases automatically from a repository ? Should > the user have control over that ? > > Stripping version number is OK. Maybe we should split the mojo into > various activities: > * generate jnlp file > * assemble zip file > * repackage zip files with old versions > > Not sure how this would be practical for the user.. > > I don't intend to spent much time solving the problem but I can > comment proposed solutions. > > As a first jot I would suggest to separate the rebundling of the zip > with older releases in a separate mojo. We can see of merging that > feature later on when one has more experience with JNLP incremental > updates. How does that sound ? > > Cheers, > > Jerome > > --------------------------------------------------------------------- > To unsubscribe from this list please visit: > > http://xircles.codehaus.org/manage_email >
