[
http://jira.codehaus.org/browse/MWEBSTART-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93598
]
Geoffrey De Smet commented on MWEBSTART-35:
-------------------------------------------
http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html
> 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
