Don't we need this for our use of JDIC Browser?
Scott, how did you make this work for TELS?
---------- Forwarded message ----------
From: Jerome Lacoste (JIRA) <[EMAIL PROTECTED]>
Date: Jan 2, 2007 2:22 AM
Subject: [jira] Closed: (MWEBSTART-8) support native libraries
To: [EMAIL PROTECTED]
[ http://jira.codehaus.org/browse/MWEBSTART-8?page=all ]
Jerome Lacoste closed MWEBSTART-8.
----------------------------------
Assignee: Jerome Lacoste
Resolution: Incomplete
Fix Version/s: 1.0-alpha-2
After thinking about it, I don't want to touch this until I get a more
complete use case. Minimal support can be added quickly (along the
lines of the incomplete patch I provided), but we probably want to
support at least <resources> attributes such as os or arch.
If someone comes with a real life test case, then I will look into it.
A good test case might be to try to support jdic
(https://jdic.dev.java.net/documentation/deployment.html).
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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"SAIL-Dev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/SAIL-Dev?hl=en
-~----------~----~----~----~------~----~------~--~---
