jMonkeyEngine-sdk/docs/libraries.md

Libraries

The Libraries of the SDK enable the user to easily manage the engine dependencies. For this there are four (!) modules in place. This design seems a bit complicated, so maybe a refactoring might be good in the long run.
To further complicate the process, netbeans is ant and xml centric however the project files are dynamically generated using gradle (because the sdk gradually moved to gradle).

The Modules

There are four modules in place: First there are the -baselibs and -libraries variants where the former are the actual engine libraries as you would specify them as dependencies and the latter are the external dependencies (i.e. dependencies needed by the engine. NiftyGUI has some dependencies, JBullet has some dependencies etc and those are in -libraries).

This means jme3-core-baselibs and jme3-core-libraries are the modules which actually store the binary data (i.e. the jar files in them). It seems to me, that those are only temporary since the other modules (jme3-project-baselibs and jme3-project-libraries) also store the jars in their release folders. Anyhow those are the modules you want to influence, their src/com/jme3/gde/project/baselibs/*.xml files are what define the actual Libraries.

If you have a look at the build.gradle file, you can see the process of building those xmls. The system is clever: You specify artifacts/dependencies and then the built xml automatically contains the dependencies specified by that dependency. Take jme3-jbullet for example:
The build.gradle for jme3-jbullet contains:

dependencies {
    compile ('java3d:vecmath:1.3.1')
    compile files('../lib/jbullet.jar', '../lib/stack-alloc.jar')
    compile project(':jme3-core')
    compile project(':jme3-terrain')
}

This leads to:

<volume>
    <type>classpath</type>
    <resource>jar:nbinst://com.jme3.gde.project.baselibs/libs/jme3-jbullet-3.1.0-stable.jar!/</resource>
    <resource>jar:nbinst://com.jme3.gde.project.libraries/libs/vecmath-1.3.1.jar!/</resource>
  </volume>
  <volume>
    <type>src</type>
    <resource>jar:nbinst://com.jme3.gde.project.baselibs/libs/jme3-jbullet-3.1.0-stable-sources.jar!/</resource>
  </volume>
  <volume>
    <type>javadoc</type>
    <resource>jar:nbinst://com.jme3.gde.project.baselibs/libs/jme3-jbullet-3.1.0-stable-javadoc.jar!/</resource>
  </volume>

Here you unfortunately see that the files() dependency could not be picked up, the reason seems to be from within gradle, at least it does not appear in jme3-jbullet's dependency list. That is why there was a needed workaround in the xml generation...

Flaws / TODOs

Apart from the automatic generation failing sometimes we have another flaw which is related to the design:
Many libraries depend on eachother like nearly all libraries depend on core. Now to not have 10 versions of jme3-core inside the libraries which might even cause the build to fail, we simply discard those inner-jme dependencies and force the user to manage them appropriately.
The Question here is if that is the right approach? For jme3_xbuf it lead to problems because things like jme3_xbuf_loader and jme3_xbuf_physics_loader aren't seperate artifacts and will be bundled into one library. Thats why there is a workaround for Xbuf.

Corelibs vs Optlibs

It seems that when the sdk itself depends on something, it has to be in corelibs, optlibs only seems to be for the user of the sdk.