[
http://jira.codehaus.org/browse/MWEBSTART-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=135795#action_135795
]
ronn chinowutthichai commented on MWEBSTART-8:
----------------------------------------------
Hi David,
> * os could be set in the classifier or in the artifactId, or groupId :
> there is no rule (I saw 2 of 3 cases)
Perhaps there should be, this is what maven is good at - defining convention. I
think enforcing user to classify their artifact as native lib is a good thing
(even if it is already specified in artifact id or group id).
> * os could be set as a subdirectory in a zip artifact, these case exists,
> could be handled with manual operation
Same as above. As long as the jar is uploaded into repository with the expected
classification it doesn't matter about the structure inside the jar.
> * support several native platform
We could add a configuration to add/override a list of os to scan for - the
default would be linux, win32, solaris
Here's what I've done to support our jdic-native.jar (we only need to support
win32 libraries) so in the repository i've got
~/.m2/repository/org/jdesktop/jdic-native/20061102/jdic-native-20061102-win32.jar
And
~/.m2/repository/org/jdesktop/jdic/20061102/jdic-20061102.pom depends on
jdic-native (with win32 classification)
No other configuration needed.
Here's a diff in our svn.
------------------------------------------------------------------------------------------------------------------------------------------------------
Index:
src/main/java/org/codehaus/mojo/webstart/generator/JarResourcesGenerator.java
===================================================================
---
src/main/java/org/codehaus/mojo/webstart/generator/JarResourcesGenerator.java
(revision 29026)
+++
src/main/java/org/codehaus/mojo/webstart/generator/JarResourcesGenerator.java
(revision 29025)
@@ -81,15 +81,9 @@
{
continue;
}
-
- // RC: hack to allow native lib to be declared properly.
- if ("win32".equalsIgnoreCase(jarResource.getClassifier())) {
- buffer.append( "<nativelib href=\"" ).append(
jarResource.getHrefValue() ).append( "\"" );
- }
- else {
- buffer.append( "<jar href=\"" ).append(
jarResource.getHrefValue() ).append( "\"" );
- }
-
+
+ buffer.append( "<jar href=\"" ).append(
jarResource.getHrefValue() ).append( "\"" );
+
if ( jarResource.isOutputJarVersion() )
{
buffer.append("
version=\"").append(jarResource.getVersion()).append("\"");
------------------------------------------------------------------------------------------------------------------------------------------------------
The out out is something like this, and obviously it only works for one
platform but that suits us fine.
<resources>
<jar href="jdic.jar" version="20061102"/>
<nativelib href="jdic-native-native.jar" version="20061102"/>
</resources>
> 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
