[
http://jira.codehaus.org/browse/MWEBSTART-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93730
]
Kevin Stembridge commented on MWEBSTART-35:
-------------------------------------------
Well, I'll leave you to ponder it. My thoughts are that the increased
complexity is minor and it is outweighed by the gains from increased
flexibility.
I'll keep an eye on this thread, so if you'd like me to implement any changes
just add another comment.
Cheers,
Kevin
> Generate a version.xml file
> ---------------------------
>
> Key: MWEBSTART-35
> URL: http://jira.codehaus.org/browse/MWEBSTART-35
> Project: Maven 2.x Webstart Plugin
> Issue Type: New Feature
> Affects Versions: 1.0-alpha-1
> Environment: n/a
> Reporter: Kevin Stembridge
> Priority: Minor
> Fix For: 1.0-alpha-2
>
>
> Generate a version.xml file as described in the [JnlpDownloadServlet
> Guide|http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/downloadservletguide.html].
> In order to do this I think we need to modify the current {{*dependencies*}}
> property of the {{*AbstractJnlpMojo*}} class. At the moment it just contains
> an includes list, an excludes list and a boolean for outputJarVersions. I
> think we need to create a new object that will represent a single Jar
> resource for the JNLP or version.xml file. So instead of the
> {{*AbstractJnlpMojo*}} class having a {{*Dependencies*}} object, it would
> have two collections of {{*JarResource*}} objects, one for includes and one
> for excludes.
> The {{*JarResource*}} object will contain whatever attributes are required to
> determine how it is represented in the JNLP and the version.xml files. E.G.
> groupId, artifactId, outputJarVersion, lazyDownload, includeInVersionXml etc.
> The downside of this approach is that the XML required in the pom.xml could
> become quite verbose. This could be mitigated by the use of sensible defaults
> so that only the groupId and artifactId would be required for most use cases.
> And in the event that all the project dependencies are to be included (with
> default values), there will be no xml required at all.
> The upside is that we gain a lot of flexibility in the generation of
> individual jarResource elements in the output files, and we give the user the
> ability to automatically generate what they can currently code by hand but
> cannot currently generate with the plugin.
> This is a configuration example using the options I mentioned:
> {code:xml}
> <configuration>
> <includedJarResources>
> <jarResource>
> <groupId>com.bogus</groupId>
> </artifactId>bogus-include</artifactId>
> <outputJarVersion>true</outputJarVersion>
> <lazyDownload>false</lazyDownload>
> <includeInVersionXml>false</includeInVersionXml>
> </jarResource>
> <jarResource>
> ...
> </jarResource>
> </includedJarResources>
> <excludedJarResources>
> <jarResource>
> <groupId>com.bogus</groupId>
> <artifactId>bogus-exclude</artifactId>
> </jarResource>
> <jarResource>
> ...
> </jarResource>
> </excludedJarResources>
> </configuration>
> {code}
> We should also provide default flags for outputJarVersion and
> includeInVersionXml so that a user can, for example, choose not to display
> any version attributes in the JNLP without having to set every flag to false.
> This is a rough guess at an implementation. I'd be interested to hear any
> other opinions on how to go about this.
--
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
