[
http://jira.codehaus.org/browse/MWEBSTART-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92915
]
Kevin Stembridge commented on MWEBSTART-35:
-------------------------------------------
I thought you might push back on the verbosity thing but I don't think its
going to be as much of a problem as you imagine. Bear in mind that the only
people who will end up writing verbose configuration will be the people who
really do need it. These are the people who have different requirements for
some of the jars in their project and they are not currently able to use the
webstart plugin. For everyone else, who will generally be treating all the jars
the same, the defaults will work just fine and their XML config will be clean.
For example, for every existing project that includes all dependencies (and
therefore doesn't specify a dependencies element), their plugin configuration
won't have to change at all. The only existing projects that will be affected
by the changes I've suggested are those that don't include every dependency.
Their config files will go from something like this...
{code:xml}
<dependencies>
<includes>
<include>someGroupId:someArtifactId</include>
</includes>
<excludes>
<exclude>someOtherGroupId:someOtherArtifactId</exclude>
</excludes>
</dependencies>
{code}
to this...
{code:xml}
<includedJarResources>
<jarResource>
<groupId>someGroupId</groupId>
<artifactId>someArtifactId</artifactId>
</jarResource>
</includedJarResources>
<excludedJarResources>
<jarResource>
<groupId>someOtherGroupId</groupId>
<artifactId>someOtherArtifactId</artifactId>
</jarResource>
</excludedJarResources>
{code}
The added verbosity here is just one extra line of code per dependency. We
could even stick with the current syntax for excluding jar resources, but for
consistency I think it would be best to use the same approach for both the
includes and excludes.
I also think there are other benefits to using a separate jarResource per
dependency:
* It is self documenting. Users will know exactly what needs to go in the
groupId and artifactId tags. Currently, we rely on the example plugin
configuration to find out what to put in an include tag.
* We would not be dependent on the undocumented internal implementation of the
IncludesArtifactFilter. i.e. the groupId:artifactId syntax that it uses. We
could still generate a string in the correct format ourselves, but at least we
are not exposing this syntax to the user.
* It is more 'type-safe'. I'm not sure this really matters, but maybe...
* It is more adaptable to future change. For example, if a future version of
the JNLP spec adds another attribute to the <jar> element, we would easily be
able to accommodate that. Also the version.xml doctype alllows a locale
attribute to be specified per jar. I haven't proposed implementing this, but if
it became a requested feature we would be better placed to introduce it.
So, I think there are many advantages to using a jarResource element and the
only disadvantage I can think of is that more (but not much more) XML is
required, but only for users that are not including every dependency. The users
that will require the more verbose configuration are users that are not
currently able to use the plugin.
> 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
