Maven / Hudson integration

Hi,

I'm actually working on a neuronal/evolution-network simulator in java for my master thesis.
The resulting framework will be licensed under GPL (or so,  don't know yet, have to read more about this issues :-) )

The program is developed with Eclipse, Hudson and Maven.

I'm using JOGL for visualize the neuronal networks and here the problem starts:

1. There are no Maven builds for JOGL et al.
2. The native libs are very ugly to integrate into the continue integration Hudson builds outside of eclipse.

I solve both problems for my local development, but I don't know what to do after I publish the simulator.

For problem #1 I'm using a bash script, which download all all jars, repack it a little bit and install it into my local maven repository.
The repacking was necessary, because the way i refer the native libs in step #2 (maven builds) and for avoiding name conflicts between the different architectures.

Here is the script:
install_jars_for_maven.sh

For problem #2 I'm using following elements in my pom.xml:
pom.parts.txt


One idea is to officially publish the maven artifacts to a public maven repository (with a "official" group/artifact id, not my local on :-) How may I ask for doing this (after we find consens :-)) ?  I am new in this forum and don't know the rules :-)

With the given script this is very easy, but I am unsure about the way.... Maybe it is more a hack than a solution...

A better and simpler way (from my side of view) would be using different names for the JNI libs for each architecture. Then we can always install all JNI libs and using one library path (so I don't need the "build.type" selection in the maven scripts and the "classifier" in the maven artifacts.)

So, are there any comments, tips or help about that topic ?

Greetings,
  Thomas

Thomas Welsch wrote

A better and simpler way (from my side of view) would be using different names for the JNI libs for each architecture. Then we can always install all JNI libs and using one library path (so I don't need the "build.type" selection in the maven scripts and the "classifier" in the maven artifacts.)

Hi Thomas,

A system like you mention (all native libraries named uniquely for platform and architecture) seems like it could work, though I haven't seen it done. If it's any consolation, I have this same situation in my Eclipse RCP apps -- I have to download all the native libraries and put them in separate directories to let them coexist

The current system does simplify the Java library loading code a lot. First, you can always just say loadLibrary( "gluegen-rt" ) instead of loadLibrary( "gluegen-rt" + platform + arch + version ). And it also saves you having to write code to simplify the os.name, os.arch, and os.version information down into the subset of names that actually require different libraries (so you don't have copies of the same library that differ only by name). For example, "gluegen-rt-64-Windows7.dll" is the same library as "gluegen-rt-64-WindowsVista.dll", so you'd really just want one DLL, and Java code to map those names together.