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 :)
Greetings
Martin
