[
http://jira.codehaus.org/browse/MWEBSTART-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135329#action_135329
]
ronn chinowutthichai commented on MWEBSTART-8:
----------------------------------------------
Thanks for the info Jerome,
We primarily going to be using JnlpDownloadServlet so we have a need to make it
work for us. I think in order to rectify internal structural differences
between the mojos properly we would have to make changes to the configuration
format (possibly remodel) - which could impact existing users. So in that
respect, doing the minimal to fix 1.0-beta-1 to get it release is probably
better in my view.
I'm always grateful for any workable patches but in terms of approach for this
particular bug, I'm wondering why we need such a verbose and explicit
configuration?
i.e.,
<nativeLibs>
<nativeLib>
<groupId>org.lwjgl</groupId>
<artifactId>lwjgl_native</artifactId>
<classifier>linux</classifier>
<os>linux</os>
</nativeLib>
</nativeLibs>
The hack I've done for us is to generate different XML snippet for different
type of classifier found in the dependencies i.e., in
JarResourcesGenerator.getDependenciesText(). This is simplistic and only works
for one native platform but we could extend the approach so that the mojo scan
through and groups dependencies of each classifier an generate separate
resources group declarations.
That way any native libs found that are classified as the available os (i.e.,
linux/win32/solaris) will be automatically picked up without any additional
configuration. If anything needs to be exclude then it should be done with the
standard dependencies exclusion. Any additional inclusion are simply defined as
another dependency. Mind you JnlpDownloadServletMojos doesn't yet support
exclusion!
The only issue that I can still see is that this doesn't solve a scenario where
you have specific java classes for a particular os. May be we could encode this
additional information into the classifiers i.e., win32(for win32 java
classes), win32-native (for win32 native libraries), linux-native,
solaris-native.
> 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
