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:[email protected]] Sent: 14 December 2010 12:45 To: [email protected] 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: [email protected] For additional commands, e-mail: [email protected] 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: [email protected] For additional commands, e-mail: [email protected]
