You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by "Andy Brook (JIRA)" <ji...@codehaus.org> on 2006/02/14 16:38:19 UTC

[jira] Created: (MPJNLP-29) Native library support?

Native library support?
-----------------------

         Key: MPJNLP-29
         URL: http://jira.codehaus.org/browse/MPJNLP-29
     Project: maven-jnlp-plugin
        Type: Bug

 Environment: Ubuntu Linux, x86_64, ibm 150 jre.
    Reporter: Andy Brook


I havent seen any examples of how native libraries are supported.  My scenario is an SWT application that uses the SWT jar from eclipse, v3.1.1 now has the .so / .dll at the root of a JAR with java classes underneath.

If it doesnt support this yet will it?  At the moment, the plugin does the lions share of signing, I just have to modify the template and hard code an additional <nativelib> tag.  It would be ideal If in addition to $dependencies in the velocity template, there was a $nativeDependencies.  This would then allow the SWT jar above to be referenced.

I see there is some code relating to native library processing that is currently commented out.  What I would like to avoid is having to extract native libraries such that the plugin can resign them again, using SWT as the example, the jar has already been signed, I just need to refer to it as a native lib.

One way is to extend the <dependencies> tag to have a natives section and in addition to specifying absolute libraries (.so / .dll ) for .jar wrapping/signing, the ideal would be to use the same descriptor as the <includes>  giving:

    <dependencies>
             <includes>
                <include>commons-logging:commons-logging</include>
                <include>commons-cli:commons-cli</include>
		<include>org.eclipse.core:boot</include>
                <include>org.eclipse.core:runtime</include>                
                <include>org.eclipse:swt</include>
                <include>org.eclipse.swt:win32-x86</include>
                <include>org.eclipse:jface</include>
                <include>org.eclipse.jface:text</include>
                <include>log4j:log4j</include>
                <include>myco:myapp</include>
             </includes>
             <!-- excludes>
                <exclude></exclude>
             <excludes-->

            <nativeIncludes>
                <include>org.eclipse.swt:win32-x86</include> <!-- this contains java classses and the native libraries -->
            </nativeIncludes>
       </dependencies>

-- 
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, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


[jira] Commented: (MPJNLP-29) Native library support?

Posted by "Lukas Theussl (JIRA)" <ji...@codehaus.org>.
    [ http://jira.codehaus.org/browse/MPJNLP-29?page=comments#action_58621 ] 

Lukas Theussl commented on MPJNLP-29:
-------------------------------------

The jnlp plugin has just been demoted to the Maven sandbox, it is not officially maintained by us anymore. If you are interested in maintaining it, please let us know on the mailing list, you can take it over to the sourceforge projects.

> Native library support?
> -----------------------
>
>          Key: MPJNLP-29
>          URL: http://jira.codehaus.org/browse/MPJNLP-29
>      Project: maven-jnlp-plugin
>         Type: Bug

>  Environment: Ubuntu Linux, x86_64, ibm 150 jre.
>     Reporter: Andy Brook

>
>
> I havent seen any examples of how native libraries are supported.  My scenario is an SWT application that uses the SWT jar from eclipse, v3.1.1 now has the .so / .dll at the root of a JAR with java classes underneath.
> If it doesnt support this yet will it?  At the moment, the plugin does the lions share of signing, I just have to modify the template and hard code an additional <nativelib> tag.  It would be ideal If in addition to $dependencies in the velocity template, there was a $nativeDependencies.  This would then allow the SWT jar above to be referenced.
> I see there is some code relating to native library processing that is currently commented out.  What I would like to avoid is having to extract native libraries such that the plugin can resign them again, using SWT as the example, the jar has already been signed, I just need to refer to it as a native lib.
> One way is to extend the <dependencies> tag to have a natives section and in addition to specifying absolute libraries (.so / .dll ) for .jar wrapping/signing, the ideal would be to use the same descriptor as the <includes>  giving:
>     <dependencies>
>              <includes>
>                 <include>commons-logging:commons-logging</include>
>                 <include>commons-cli:commons-cli</include>
> 		<include>org.eclipse.core:boot</include>
>                 <include>org.eclipse.core:runtime</include>                
>                 <include>org.eclipse:swt</include>
>                 <include>org.eclipse.swt:win32-x86</include>
>                 <include>org.eclipse:jface</include>
>                 <include>org.eclipse.jface:text</include>
>                 <include>log4j:log4j</include>
>                 <include>myco:myapp</include>
>              </includes>
>              <!-- excludes>
>                 <exclude></exclude>
>              <excludes-->
>             <nativeIncludes>
>                 <include>org.eclipse.swt:win32-x86</include> <!-- this contains java classses and the native libraries -->
>             </nativeIncludes>
>        </dependencies>

-- 
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, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org