[
http://jira.codehaus.org/browse/MWEBSTART-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_88384
]
Craig Sumner commented on MWEBSTART-8:
--------------------------------------
Any SWT-based application should make a decent use case.
An application which shows an empty SWT shell on the screen requires a
dependency like this:
<dependency>
<groupId>org.eclipse</groupId>
<artifactId>swt</artifactId>
<version>3.2.0</version>
</dependency>
This contains the java code. In our case, it also contains the windows dll. We
stuffed the windows dll in the main swt java jar in order to reduce the manual
work required after running mvn webstart:jnlp. Now all we have to do is
duplicate the above dependency line in the launch.jnlp file, and mark the
duplicate as nativelib.
This is a workaround, and might not be your best use case.
Instead, I would expect most users to keep the above dependency java-only, and
add a dependency like this:
<dependency>
<groupId>org.eclipse</groupId>
<artifactId>swt-win32</artifactId>
<version>3232</version>
<type>dll</type>
</dependency>
This works, well enough to pull the dll down to the local maven repo. I wish
Eclipse would put the dll on the classpath automatically, but it isn't that
smart.
But, if the webstart plugin could:
- recognize the native libs based on type
- jar them
- sign them along with everybody else
- include them as nativelib in the jnlp
that would be a great start.
Additionally, one would want to map them to environments in the pom. (Windows
vs Mac vs Linux...)
> support native libraries
> ------------------------
>
> Key: MWEBSTART-8
> URL: http://jira.codehaus.org/browse/MWEBSTART-8
> Project: Maven 2.x Webstart Plugin
> Issue Type: New Feature
> Reporter: Jerome Lacoste
> Assigned To: Jerome Lacoste
> Fix For: 1.0-alpha-2
>
> Attachments: MWEBSTART-8.diff
>
>
> 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
