At first there is another plugin (maven-native-plugin at codhaus). It is especially focused on JNI and on one-platform compilations. However it does not solve my example (let maven choose which platform it needs without needing profiles). With maven-native-plugin you need to provide many profiles for each platform and you need multiple maven projects (one for each platform). Some of the users decided to choose the maven-native-plugin. I personally expect that we are able to merge them in the near future since maven-native-plugin has same benefits and maven-nar-plugin has other benefits.
We did not talk about it because there is enough homework to be done for maven-nar-plugin. At first we must re-merge all the forks that are living.
The second reason is simple: The project lead (and lonesome developer) did not have enough time for it. However we (let us call the commuity) created a new github organization, the original author moved the project to this new organization and now we are doing the homeworks: https://github.com/maven-nar/
Of course in the future of the project there must be an active team of developers and an active project lead.
From my perspective I think there's some interesting potential
here.
I'd like to invite others to weigh in, especially Krzysztof &
Alex given their work to get the swt & equinox launchers
builds going for our CBI work.
The low/no activity for some time is a bit concerning. What do you
think is causing this?
Andrew
On 10/15/2012 09:05 AM, Martin Eisengardt wrote:
Hi.
So let me give an example for maven-nar-plugin to clear out
the benefit. Of course this would mean to refactor some of the
projects. But don't only think of swt but of other projects/
eclipse plugins that use JNI. Of course this may influence
tycho but lets clear out one on one.
maven-nar-plugin devides the native build from java build.
For jni the native header files can be generated (although
thats not the interesting point).
A java library/ application can add dependencies similar to
the following:
<dependency>
<groupId>org.eclipse</groupId>
<artifactId>some-native-lib</artifactId>
<type>nar</type>
</dependency>
The main goal is that maven-nar-plugin is responsible to
choose the correct native library. Either from properties or
from the machine information itself. So you do not have to
wonder how your java application is being used. If user A uses
it on a windows machine, maven-nar-plugin will choose the
windows binary. If User B uses it on a linux machine,
maven-nar-plugin will choose windows etc.
There should be no more properties and profiles and other
things.
Of course this does not match the current SWT-binaries
project structue and you might need some refactoring. However
I think this could be done in future. If you choose to use
maven-nar-plugin one day it does not mean to migrate swt
today.
Currently there were some suggestions on the future of
maven-nar-plugin because ion the past it was nearly inactive
for three years, there had been 20 forks etc. And moving it to
eclipse foundation was one of the options on the future of
this project :)
