[
http://jira.codehaus.org/browse/MWEBSTART-8?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134888#action_134888
]
Jerome Lacoste commented on MWEBSTART-8:
----------------------------------------
David,
Some comments. Great if you can address them
* can you fix the code style ? In particular related. do a mvn site and look at
the checkstyle report for your new code.
* move
StringBuffer buffer = new StringBuffer();
just before
if (!libsByOsArch.isEmpty()) {
we're not coding in C :)
* + 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 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
is that something you can contribute ?
* + * Copyright 2005 Nick C . Who 's Nick ?
* return new ArrayList(0); -> Collections.EMPTY_LIST
* the best thing for me would be to get a simple integration test. Look at
src/it/... and create a test project there.
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.
> 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
