[
http://jira.codehaus.org/browse/MWEBSTART-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134908#action_134908
]
David Bernard commented on MWEBSTART-8:
---------------------------------------
Hi Jerome,
I could work on your request (next week-end at home) :
* can you fix the code style ? In particular related. do a mvn site and
look at the checkstyle report for your new code.
OK
* move
StringBuffer buffer = new StringBuffer();
just before
if (!libsByOsArch.isEmpty()) {
we're not coding in C :)
I didn't re-read the original patch (only adapt it to work)
* + public static String getDependenciesText(AbstractJnlpMojo config,
NativeLibResourcesGenerator nativeLibGen)
The new dummy javadoc doesn't add anything -> remove it.
??
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
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 ?
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.
* return new ArrayList(0); -> Collections.EMPTY_LIST
+1
* the best thing for me would be to get a simple integration test. Look at
src/it/... and create a test project there.
see above.
Now once you fix this, I will commit it. The only thing that will missing
will be support of native libs in the jnlp download servlet mojo. I am trying
to get them more similar feature/code wise.
thanks for your feedback.
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.
/davidB
> 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
