[
http://jira.codehaus.org/browse/MWEBSTART-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_96408
]
Kevin Stembridge commented on MWEBSTART-38:
-------------------------------------------
I've come across a few design issues that I think need to be sorted out in
order to help the new mojo fit in nicely with the existing ones.
At the moment, all of the functionality of the existing 3 mojos is implemented
in AbstractJnlpMojo, which is fine because they all do exactly the same thing.
The new mojo will need to do 2 things differently:
# After signing and compressing jars, they will be copied to a target directory
(or maybe processed in this target directory), whereas the existing mojos
create a zip archive and attach it to the project.
# The jars to be included in the JNLP bundle can't be declared as project
dependencies (due to single version limitation).
The first issue is not going to be a big deal. For the second issue, I propose
declaring a list of jar resources within the plugin configuration, much the
same way as the dependency plugin declares a list of artifact items. The new
mojo will then use the artifactFactory and artifactResolver to copy these files
into a working directory prior to compressing and signing. This is not going to
be a big deal either but it is a different approach to the way the existing
mojos do it. What I would like to suggest is that the existing mojos be
modified to use the same concept to retrieve dependencies. I can see the
following advantages:
# All mojos use a consistent approach, which would make it *much* easier to
implement the new mojo.
# We can create a wrapper object (e.g. JarResource) for each Artifact which
will allow us to define extra attributes for each artifact individually.
## We could define a mainClass element on a JarResource which would allow the
user to explicitly declare which jar contains the main class and allow us to
process each jar more efficiently.
## We would have the flexibility to treat each jar resource individually if
this becomes a requirement in the future, e.g. outputVersionNumber,
lazyDownload, locales etc.
Jerome, let me know what you think.
> Create a new mojo for use within JnlpDownloadServlet webapp projects
> --------------------------------------------------------------------
>
> Key: MWEBSTART-38
> URL: http://jira.codehaus.org/browse/MWEBSTART-38
> Project: Maven 2.x Webstart Plugin
> Issue Type: New Feature
> Affects Versions: 1.0-alpha-1
> Environment: n/a
> Reporter: Kevin Stembridge
> Fix For: 1.0-alpha-2
>
>
> The plugin doesn't currently cater for jnlp projects that will be bundled in
> a webapp and served up by the JnlpDownloadServlet.
> To be suitable for this type of project, the following features are required:
> - The mojo should be usable within a war project.
> - It won't produce its own artifact. The jars will be processed and stored in
> a subdirectory of the exploded war target directory.
> - A version.xml file is optionally generated.
> - Enables multiple versions of an artifact to be included in the bundle. This
> is to allow the JnlpDownloadServlet to provide jardiff updates to clients.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
