[
http://jira.codehaus.org/browse/MWEBSTART-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134923#action_134923
]
Jerome Lacoste commented on MWEBSTART-8:
----------------------------------------
> I could work on your request (next week-end at home) :
David, all in all sounds great.
>I didn't re-read the original patch (only adapt it to work)
OK :) I didn't mean to imply that you were the one to have coded the file, just
as there are a couple of small things to clean, that you could do it !
* + public static String getDependenciesText(AbstractJnlpMojo config,
NativeLibResourcesGenerator nativeLibGen)
>> The new dummy javadoc doesn't add anything -> remove it.
> ??
the empty javadoc just before the method getDependenciesText
>> Don't change the visibility of the method without reason neither. The class
>> uses a default and not public modifier as it is only exposed
>> for unit testing purposes.
> I change it with a reason, but I didn't remember why (I've some trouble with
> eclipse, so I can't check now). I'll fix or fine the reason
OK :)
>> I don't like much how we expose the native lib generator parameter here.
>> I'll look into this later on.
>>
>> we ought to have new unit tests for the following case:
>> * ignoring native libs when generating getDependenciesText()
>> * test getNativeLibDependenciesText
> agree, I never used shitty, I took a quick overlook, but I didn't find a
> existing test case that check the content of the jnlp. I search for it
> as an example to create the a test for nativelibs.
> Could you point me where to find the right sample test ?
For the unit tests, use plain JUnit. For the integration tests (i.e. full POM
example), use shitty.
For your particular integration tests, just pick one simple itxxx project that
uses jnlp-inline attached to a particular phase, and change it so that it uses
native libraries). Not sure if there are some trusted simple native project
available somewhere for us to test.
Otherwise we could create one ourselves. E.g. one helloworld-native project
with a single native function that does something like
String hello(String name) -> hello("Jerome") could return "Hello Jerome!".
we could use http://mojo.codehaus.org/maven-native/native-maven-plugin/ and
generate it on the fly, but I guess we need to compile it and release it for
several platforms for the test to be meaningful.
Not sure how one deals with release of native projects that need to be compiled
for several platforms...
>> is that something you can contribute ?
> I'll try
>> * + * Copyright 2005 Nick C . Who 's Nick ?
> I didn''t, it is part of the origanal patch I didn't change the license, only
> add my name in the javadoc.
OK. Strange as his name is nowhere on the list of people in that issue. Maybe a
copy paste issue. I think I will take it out.
> I probably provide other contributions :
>
> * I found an other issue (resource are copied under libDir, I'll fix it)
> * I would like to generate html for jnlp/applet with velocity.
OK. Just provide them as separate patches and open new Jira issues.
Cheers,
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
