Native dependencies best practices

[Ruben Garat <ru...@gmail.com>]

Hi, I am trying to help get a project (Lightweight Java Game Library 
<http://lwjgl.org/>) into Maven Central repository.
This project is the most used way for java games to use opengl.

The project is made of a main jar lwjgl.jar and some natives for each 
platform.

I have to main questions:

*What should be the id of the native artifacts:*

For now, what I am using is having a classifier composed of 
"natives-${platform}" like natives-win, natives-mac, natives-linux. I 
think this is a useful naming convention because it allows the creation 
of a plugin (maven-natives-plugin 
<http://code.google.com/p/mavennatives/>) that matches those classifiers 
and unpacks the natives. This allows you to add them to the 
java.library.path. Also it allows the creation of an eclipse plugin so 
that everything is configured automatically.


*The other issue is what should be the artifactId of the native artifacts:*
In my personal repository I added the natives using the same artifactId 
as the main artifact, but with the natives-${platform} classifier, and 
added the natives as dependencies of the main artifact.

    *    main artifact: groupId:org.lwjgl - artifactId: lwjgl
    *    natives artifacts: groupId: org.lwjgl - artifactId: lwjgl -
      classifier: natives-${platform}

This solutions works great because you don't have to declare the natives 
when you add a dependency.
The problem came when I tried create a build of the project made with 
maven, because the main artifact depends on the natives, but they share 
the groupId and artifactId maven complains that there is a cycle and 
refuses to build.
Shouln't it work if I use runtime as scope for the native dependencies? 
At build time they should not be used, so the build shouldn't complain 
about a cycle and then I can attach them to the result of the build.
I could use a different artifactId, but there is no natural name for 
that, the only thing that comes to mind, is oldartifactId-natives but 
that would clash with the proposed naming convention using 
natives-${platform} as classifier.


so the questions are:

    *      is the proposed naming convention for artifacts with natives
      (natives-${platform}) a good one? is there anyone better?
    *      should I be able to define cycles if the dependencies have
      runtime scope?. If I can't or is not recommended what would you
      recommend as an artifactId?

thanks for the help

Rubén

RE: Native dependencies best practices

["Haszlakiewicz, Eric" <EH...@transunion.com>]

>-----Original Message-----
>From: Ruben Garat [mailto:ruben01.dev@gmail.com]
>Sent: Saturday, January 22, 2011 9:59 AM
>To: Maven Users List
>Subject: Native dependencies best practices
>
>Hi, I am trying to help get a project (Lightweight Java Game Library
><http://lwjgl.org/>) into Maven Central repository.
>This project is the most used way for java games to use opengl.
>
>The project is made of a main jar lwjgl.jar and some natives for each
>platform.
>
>I have to main questions:
>
>*What should be the id of the native artifacts:*
>
>*The other issue is what should be the artifactId of the native artifacts:*
>
>    *    main artifact: groupId:org.lwjgl - artifactId: lwjgl
>    *    natives artifacts: groupId: org.lwjgl - artifactId: lwjgl -
>      classifier: natives-${platform}
>so the questions are:
>
>    *      is the proposed naming convention for artifacts with natives
>      (natives-${platform}) a good one? is there anyone better?

There is a maven-nar-plugin that already does some of what you're talking about.  You might want to take a look at that.
Like many (most?) plugins, the documentation is a bit lacking.  In brief, the way it works is that there is a classifier-less artifact that contains a "nar.properties" file.  This classifier-less artifact is the one you list as a dependency in your pom file.   This properties file defines the GAV+C coordinates to get the platform specific artifacts.  e.g.:

nar.noarch=
nar.static=org.lwjgl:lwjgl-native:nar:${aol}

The nar plugin replaces the "${aol}" bit with something that describes the platform you are on.  e.g. "amd64-Linux-g++", "IA64W-HP-UX-g++", etc...  Note that the values it uses for this can be a bit tricky to figure out, and I haven't been able to figure out how they are calculated.  For my purposes, I ended up running maven through strace and finding what it was trying to download.  (you could probably also look in the logs of your repository manager)

Your artifactId for the native artifacts should be different than your main artifact.  It sounds like it's really a separate piece and should be defined as such.  That will probably solve your cycle problems.

>This solutions works great because you don't have to declare the natives
>when you add a dependency.

You can include "nar" type dependencies in your pom file and it will automatically pull in the right native version, but you still need to explicitly say that you're pulling it in.

You can also use the nar plugin to *build* the native portion, but I assume you don't actually want to do that, since it's a whole bunch more work.  I ended up creating the nar artifacts by hand and uploading them to my Nexus instance using "mvn deploy:deploy-file ..."

eric

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org