You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Peter Bridge <pe...@hotmail.com> on 2010/12/14 13:45:23 UTC
Handling native dependencies via classifier(s)
My project depends on a 3rd party library for OpenGL + Java called JOGL
(http://jogamp.org/jogl/www/)
The library is currently not maven-ized and I'm trying to find the best
way to achieve that. My progress is documented at:
http://jogamp.762907.n3.nabble.com/maven2-artifacts-tp1935908p1935908.html
To get started I'm just manually putting the JOGL jars into a local
repository. Currently this is 4 jar files and each jar has a dependency
on a couple of native libs (.dll .jnilib .so etc) which I'm zipping and
then unpacking again for my project with:
<!-- Unpack native libs -->
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>generate-sources</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/lib</outputDirectory>
<includeTypes>zip</includeTypes>
</configuration>
</execution>
</executions>
</plugin>
For each Jar I have a block like this:
<dependency>
<groupId>com.jogamp.jogl</groupId>
<artifactId>jogl-all</artifactId>
<version>${jogl.version}</version>
</dependency>
<dependency>
<groupId>com.jogamp.jogl</groupId>
<artifactId>jogl-natives</artifactId>
<version>${jogl.version}</version>
<classifier>osx-universal</classifier>
<type>zip</type>
</dependency>
Now this is going to get ugly quite fast, ie once I add all 5 supported
native platforms. It also feels wrong, although I'm very new to
maven2. Somehow I expected that there would be a way to tie the native
dependencies together with the jar in a more elegant way, maybe
something like:
<dependency>
<groupId>com.jogamp.jogl</groupId>
<artifactId>jogl-all</artifactId>
<version>${jogl.version}</version>
<classifier>sources</classifier>
<classifier>javadoc</classifier>
<classifier>osx-universal</classifier>
<classifier>windows</classifier>
<classifier>linux</classifier>
...
</dependency>
I considered some kind of wrapper pom for each jar, but it also feels
like a work-around. ie the jar can't be used without the natives, so
somehow they should be configured as a single artifact/entity/dependency.
The next issue I trip over with native handling, is eclipse:eclipse.
Looking at the sources, it seems to take account of classifiers for
'sources' and 'javadoc' but I don't see anything for handling of native
directories. ie the EclipseClasspathWriter and AbstractIdeSupportMojo
would need to output something like this:
<classpathentry kind="var"
path="M2_REPO/com/jogamp/jogl/jogl-all/2.0.251/jogl-all-2.0.251.jar">
<attributes>
<attribute
name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY"
value="client/lib"/>
</attributes>
</classpathentry>
Now I'm thinking I can't be the first person to trip over this, but
google isn't giving much help. So I'm wondering how other people are
dealing with this?
Or is it just that maven currently just isn't designed to work with
native dependencies?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Handling native dependencies via classifier(s)
Posted by Peter Bridge <pe...@hotmail.com>.
Thanks for that.
re: jar. Is there an advantage building a jar for natives rather than a
zip?
re: single jar natives. makes sense, and saves a lot of manual config in
eclipse to add each native path later (I often need to switch
versions). Although I wonder how this will affect my final packaging
when I want to build platform specific targets.
re: source&java docs. It sounds like an all or nothing approach, I was
trying to find a way to only get the sources and javadocs for a couple
of my dependencies.
re: launch config. Does maven create these for you?
does anyone know if maven 3 is going to address the deficiency with
native lib handling?
Thanks in advance. Peter Bridge
On 2010-12-14 14:45, Niels B Nielsen wrote:
> Well, I can tell you how I deal with it..
>
> I have all editions of our native libraries bundled inside a single jar file, I created.
> ./win32/libsomething.dll
> ./win64/libsomething.dll
> ./unix/x32/something.so
> etc
>
> and unpacks that into lib (similar to what you did).
> During test and execution we navigate the right structure and set java.library.path.
>
> the eclipse plugin surely has some shortcomings, especially in the native ares.
> When setting up for eclipse, I use 'mvn eclipse:eclipse -DdownloadSources -DdownloadJavadocs', and then just reference the library in the launch configuration (java.library.path).
>
> Hope that helps.
>
> P.S. I would never add a dependency on source and javadocs etc, as the main resolve would transitively include these in the classpath.
>
> Niels B Nielsen | Lead Engineer
> J.P. Morgan | IBTech Global Rates Derivatives
>
>
>
> -----Original Message-----
> From: Peter Bridge [mailto:peter_bridge@hotmail.com]
> Sent: 14 December 2010 12:45
> To: users@maven.apache.org
> Subject: Handling native dependencies via classifier(s)
>
> My project depends on a 3rd party library for OpenGL + Java called JOGL
> (http://jogamp.org/jogl/www/)
>
> The library is currently not maven-ized and I'm trying to find the best
> way to achieve that. My progress is documented at:
> http://jogamp.762907.n3.nabble.com/maven2-artifacts-tp1935908p1935908.html
>
> To get started I'm just manually putting the JOGL jars into a local
> repository. Currently this is 4 jar files and each jar has a dependency
> on a couple of native libs (.dll .jnilib .so etc) which I'm zipping and
> then unpacking again for my project with:
>
> <!-- Unpack native libs -->
> <plugin>
> <artifactId>maven-dependency-plugin</artifactId>
> <executions>
> <execution>
> <id>unpack-dependencies</id>
> <phase>generate-sources</phase>
> <goals>
> <goal>unpack-dependencies</goal>
> </goals>
> <configuration>
>
> <outputDirectory>${basedir}/lib</outputDirectory>
> <includeTypes>zip</includeTypes>
> </configuration>
> </execution>
> </executions>
> </plugin>
>
>
> For each Jar I have a block like this:
>
> <dependency>
> <groupId>com.jogamp.jogl</groupId>
> <artifactId>jogl-all</artifactId>
> <version>${jogl.version}</version>
> </dependency>
> <dependency>
> <groupId>com.jogamp.jogl</groupId>
> <artifactId>jogl-natives</artifactId>
> <version>${jogl.version}</version>
> <classifier>osx-universal</classifier>
> <type>zip</type>
> </dependency>
>
> Now this is going to get ugly quite fast, ie once I add all 5 supported
> native platforms. It also feels wrong, although I'm very new to
> maven2. Somehow I expected that there would be a way to tie the native
> dependencies together with the jar in a more elegant way, maybe
> something like:
>
> <dependency>
> <groupId>com.jogamp.jogl</groupId>
> <artifactId>jogl-all</artifactId>
> <version>${jogl.version}</version>
> <classifier>sources</classifier>
> <classifier>javadoc</classifier>
> <classifier>osx-universal</classifier>
> <classifier>windows</classifier>
> <classifier>linux</classifier>
> ...
> </dependency>
>
> I considered some kind of wrapper pom for each jar, but it also feels
> like a work-around. ie the jar can't be used without the natives, so
> somehow they should be configured as a single artifact/entity/dependency.
>
> The next issue I trip over with native handling, is eclipse:eclipse.
> Looking at the sources, it seems to take account of classifiers for
> 'sources' and 'javadoc' but I don't see anything for handling of native
> directories. ie the EclipseClasspathWriter and AbstractIdeSupportMojo
> would need to output something like this:
>
> <classpathentry kind="var"
> path="M2_REPO/com/jogamp/jogl/jogl-all/2.0.251/jogl-all-2.0.251.jar">
> <attributes>
> <attribute
> name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY"
> value="client/lib"/>
> </attributes>
> </classpathentry>
>
>
> Now I'm thinking I can't be the first person to trip over this, but
> google isn't giving much help. So I'm wondering how other people are
> dealing with this?
>
> Or is it just that maven currently just isn't designed to work with
> native dependencies?
>
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Handling native dependencies via classifier(s)
Posted by Niels B Nielsen <ni...@jpmorgan.com>.
Well, I can tell you how I deal with it..
I have all editions of our native libraries bundled inside a single jar file, I created.
./win32/libsomething.dll
./win64/libsomething.dll
./unix/x32/something.so
etc
and unpacks that into lib (similar to what you did).
During test and execution we navigate the right structure and set java.library.path.
the eclipse plugin surely has some shortcomings, especially in the native ares.
When setting up for eclipse, I use 'mvn eclipse:eclipse -DdownloadSources -DdownloadJavadocs', and then just reference the library in the launch configuration (java.library.path).
Hope that helps.
P.S. I would never add a dependency on source and javadocs etc, as the main resolve would transitively include these in the classpath.
Niels B Nielsen | Lead Engineer
J.P. Morgan | IBTech Global Rates Derivatives
-----Original Message-----
From: Peter Bridge [mailto:peter_bridge@hotmail.com]
Sent: 14 December 2010 12:45
To: users@maven.apache.org
Subject: Handling native dependencies via classifier(s)
My project depends on a 3rd party library for OpenGL + Java called JOGL
(http://jogamp.org/jogl/www/)
The library is currently not maven-ized and I'm trying to find the best
way to achieve that. My progress is documented at:
http://jogamp.762907.n3.nabble.com/maven2-artifacts-tp1935908p1935908.html
To get started I'm just manually putting the JOGL jars into a local
repository. Currently this is 4 jar files and each jar has a dependency
on a couple of native libs (.dll .jnilib .so etc) which I'm zipping and
then unpacking again for my project with:
<!-- Unpack native libs -->
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack-dependencies</id>
<phase>generate-sources</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<outputDirectory>${basedir}/lib</outputDirectory>
<includeTypes>zip</includeTypes>
</configuration>
</execution>
</executions>
</plugin>
For each Jar I have a block like this:
<dependency>
<groupId>com.jogamp.jogl</groupId>
<artifactId>jogl-all</artifactId>
<version>${jogl.version}</version>
</dependency>
<dependency>
<groupId>com.jogamp.jogl</groupId>
<artifactId>jogl-natives</artifactId>
<version>${jogl.version}</version>
<classifier>osx-universal</classifier>
<type>zip</type>
</dependency>
Now this is going to get ugly quite fast, ie once I add all 5 supported
native platforms. It also feels wrong, although I'm very new to
maven2. Somehow I expected that there would be a way to tie the native
dependencies together with the jar in a more elegant way, maybe
something like:
<dependency>
<groupId>com.jogamp.jogl</groupId>
<artifactId>jogl-all</artifactId>
<version>${jogl.version}</version>
<classifier>sources</classifier>
<classifier>javadoc</classifier>
<classifier>osx-universal</classifier>
<classifier>windows</classifier>
<classifier>linux</classifier>
...
</dependency>
I considered some kind of wrapper pom for each jar, but it also feels
like a work-around. ie the jar can't be used without the natives, so
somehow they should be configured as a single artifact/entity/dependency.
The next issue I trip over with native handling, is eclipse:eclipse.
Looking at the sources, it seems to take account of classifiers for
'sources' and 'javadoc' but I don't see anything for handling of native
directories. ie the EclipseClasspathWriter and AbstractIdeSupportMojo
would need to output something like this:
<classpathentry kind="var"
path="M2_REPO/com/jogamp/jogl/jogl-all/2.0.251/jogl-all-2.0.251.jar">
<attributes>
<attribute
name="org.eclipse.jdt.launching.CLASSPATH_ATTR_LIBRARY_PATH_ENTRY"
value="client/lib"/>
</attributes>
</classpathentry>
Now I'm thinking I can't be the first person to trip over this, but
google isn't giving much help. So I'm wondering how other people are
dealing with this?
Or is it just that maven currently just isn't designed to work with
native dependencies?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org