Bug 1118

Here is the discussion IRC log with Goussej:
<GiGurra> Hi. I spoke to goussej on the forums (http://forum.jogamp.org/Help-How-to-Build-an-executable-JAR-with-SBT-JOGL-Scala-td4033830.html#none) about a jar loading/packaging problem and he told me to come here and see if anyone knew how to solve my problem
<GiGurra> In particular he told me to contact someone named Mark, not sure if Mark is here atm but I dont see his name on the right
* monsieur_max (~maxime@ip-46.net-81-220-153.grenoble.rev.numericable.fr) has joined
* gouessej (52794ad6@gateway/web/freenode/ip.82.121.74.214) has joined
<gouessej> Hi
<gouessej> GiGurra: Please read my reply
<gouessej> GiGurra: rmk0 knows Maven far better than me
<GiGurra> Thanks, I'll try to figure out some solution. Do you know if the question has come up before?
<GiGurra> Or are there too few people interested in both JOGL and scala
<gouessej> I don't think that the question has been asked before
<gouessej> Why not contacting the sbt maintainers to see what they suggest?
<GiGurra> Yes I'm thinking about that too
<GiGurra> but I'm not sure. Assembly is not part of sbt
<GiGurra> it's justa plugin
<GiGurra> sbt does not provide any ways for building an executable jar afaik, so you need to use one of the packaging tools
<GiGurra> First id need to figure out how the file structure inside my jar should work for JOGL to run. Then once I know that, Ican contact the sbt assembly, pack or one-jar people and see if they want to support it
* monsieur_max1 (~maxime@ip-46.net-81-220-153.grenoble.rev.numericable.fr) has joined
* monsieur_max has quit (Ping timeout: 264 seconds)
<gouessej> Then, you should look at the paragraph I quoted
<gouessej> It shows in which location you must put the native libraries to allow GlueGen to find them, extract them and load them
<GiGurra> yes, thats the page Ive been studying mroe hehe
<GiGurra> The simplest might be multi jar, even though it's discouraged
<gouessej> Then, what is wrong??? /natives/<os.and.arch>/
<gouessej> I have an idea...
<gouessej> This should help: http://forum.jogamp.org/Fat-jar-deployment-method-ant-recipe-tp4032213p4032229.html
<gouessej> Look at the prefixes
<gouessej> Now don't tell me that you don't know where to put the native libraries :)
<gouessej> https://jogamp.org/jogl/doc/deployment/JOGL-DEPLOYMENT.html#NativeJARFiles
<GiGurra> Goussej, yes thx. Thats not the problem. I know there are many places to put them. Here's the problem:
<GiGurra> I need to come up with a simple enough suggestion for proposing a new build setting to the assembly/pack/one-jar plugin createors, good enough for them to accept. Otherwise we'll just run into "you're doing it wrong" -> "no you are"
<GiGurra> maven/sbt/gradle, all being fairly high level declarative build tools compared to ant, you're not supposed to work on details in them
<GiGurra> so I may just end up with a custom script to build my jar file, and just use SBT for development
<gouessej> Gradle allows to call Ant
<gouessej> Maven too
<GiGurra> I'm sure it does that is not the point
<GiGurra> sbt can all any console command too
<GiGurra> I may just end up calling ant to produce my jar in the end
<GiGurra> just because I cannot get it to work with sbt for example
<gouessej> There is already a limitation with One-JAR
<GiGurra> but then id need to define the dependencies again... The point of sbt/maven/etc is to be able to define deps once and be done with it, let the tool figure out the rest :)
<GiGurra> yeah, I dont care about one-jar tbh
<GiGurra> getting assembly to work would be the best, and I think the subfolder naming scheme is the best solution for that
<gouessej> Do you think that you have a chance to make it work with assembly then?
<GiGurra> yes
<GiGurra> assembly just merges everything in the dir structure given by the original jars. I'll just need to have them implement some retarget-filter
<gouessej> Good idea
<gouessej> In my humble opinion, the only helpful thing that could be done in JogAmp consists in providing a JAR with all native libraries respecting the naming convention
<GiGurra> YES
<GiGurra> if that is possible
<GiGurra> :)
<GiGurra> that would be great. I have to leave now. Good talking to you, I'll leave irc on
<gouessej> It breaks nothing :) You can make a bug report and mark it as a RFE
<gouessej> Ok bye
<GiGurra> bye, thx
<gouessej> you're welcome
* gouessej has quit (Quit: Page closed)

Writing an Ant task that merges the JARs containing the native libraries into a single JAR by copying all files in /natives/*/ is trivial but I don't know where and when it should be called as a machine is able to build only the native libraries of its platform whereas the other native libraries are necessary to create gluegen-rt-all-natives.jar, jogl-all-natives.jar, jocl-all-natives.jar and joal-all-natives.jar.

Currently we use Mark's scripting to produce maven artifacts.

Then .. we would need to have those all-natives etc in the first place,
for all jogamp modules.

I don't really see the benefit here,
as Julien mentioned - far-jar is supported but we don't produce 'em yet.

.. quite undecided.

(In reply to comment #3)
> Currently we use Mark's scripting to produce maven artifacts.
> 
> Then .. we would need to have those all-natives etc in the first place,
> for all jogamp modules.
> 
> I don't really see the benefit here,
> as Julien mentioned - far-jar is supported but we don't produce 'em yet.
> 
> .. quite undecided.

The problem is that some build tools aren't flexible enough (unlike Ant) to create those JARs easily. Johan's suggestion is the least invasive solution we found as a compromise to make it work with SBT. It doesn't require any change inside GlueGen.

Moreover, each time someone has to make a fat JAR, we have to show her/him the documentation. If we provided some *-all-natives JARs, we would just have to tell her/him to keep the same structure when merging the JARs. If the build tool is unable to do that, then we'll have to blame it ;)

Finally, it would help to obtain a single JAR (at least for desktop environments) for all JogAmp APIs, which are often used in academical contexts by newbies. I often have to enumerate tons of JARs in the tutorials and there is always someone who picks the wrong JARs for the native libraries.

Maybe this RFE is a better solution:
https://jogamp.org/bugzilla/show_bug.cgi?id=1145

We expect the implementation of Bug 1172 to resolved this bug all native jars uses the fat-jar internal layout. All plugins that combine jars into one should work. jogamp 2.3.2 will be the first release using the natives/os.and.arch internal jar layout.

*** This bug has been marked as a duplicate of bug 1172 ***