[
http://jira.codehaus.org/browse/MWEBSTART-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135284#action_135284
]
Jerome Lacoste commented on MWEBSTART-8:
----------------------------------------
Ronn,
different contributors wrote the standard jnlp mojos and the
JnlpDownloadServlet one. The later was written after the other and came with
more feature. I haven't taken the time to merge them both. I haven't used
webstart in any of my personal or professional projects in 2 years, so I have
less incentive to fix this as if I was using it. Help appreciated :)
The reason for the configuration discrepancy between the various mojos is why
webstart 1.0 is not out yet, nor in beta. I want to fix this issue,
MWEBSTART-58 and allow the jnlp mojos to have jarArtifacts as the jnlp download
servlet does (these last 2 will impact the configuration format). Once those
are fixed, 1.0-beta-1 can be released and we can go towards 1.0.
Another solution is to release 1.0 now and then go towards 2.0 to notify of the
broken format, or to support both old and new format. Comments appreciated :)
Jerome
> support native libraries
> ------------------------
>
> Key: MWEBSTART-8
> URL: http://jira.codehaus.org/browse/MWEBSTART-8
> Project: Maven 2.x Webstart Plugin
> Issue Type: New Feature
> Components: jnlps
> Reporter: Jerome Lacoste
> Assignee: Jerome Lacoste
> Fix For: 1.0-alpha-3
>
> Attachments: MWEBSTART-8.diff, MWEBSTART-8a.diff, MWEBSTART-8b.patch,
> MWEBSTART-8c.patch
>
>
> nativelib are resiyrces that are tagged in the following way in a jnlp file:
> <resources os="Windows">
> <nativelib href="thedll.jar"/>
> </resources>
> To support nativelib at the same level of simplicity that the usual
> dependencies are supported requires to:
> - automatically identify them from
> - automatically wrap .dll .so files in jar files
> Q: what about jar files that are architecture dependent?
> In maven 1 it was possible to attach some properties to the dependencies. But
> we cannot use that anymore.
> We could
> 1- mark the dependencies in the pom using the correct <type> in the pom. E.g.
> <type>dll</type>
> 2- make the plugin automatically wrap the native dependency inside a jar.
> 3- automatically fill up the <nativelib> elements using some sort of filter
> mecanism
> <resources os="Windows">
> $allDependencies.filter("dll")
> </resources>
> ??
> $dependencies would implicitly map to $allDependencies.filter("jar") for
> backward compatibility.
> Better: the filter() argument might be a JDK 1.4 regex matching a dependency
> notation. That way we solve the architecture issue (we can match names,
> types, etc..)
> That's just one idea. We can perhaps do better? Let me know how you see it.
--
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
