Explorar el Código

Fixes #81 - Manual Workaround for XBuf Dependencies, so that the xbuf_loader and others get properly added to the jme3_xbuf library.

MeFisto94 hace 8 años
padre
commit
3b1bf05457
Se han modificado 2 ficheros con 22 adiciones y 0 borrados
  1. 16 0
      build.gradle
  2. 6 0
      docs/libraries.md

+ 16 - 0
build.gradle

@@ -426,6 +426,22 @@ task createProjectXml(dependsOn: configurations.corelibs) <<{
                 
                 resource "jar:nbinst://com.jme3.gde.project.baselibs/libs/${jmeJarFiles[0]}!/"
                 
+                /* Usually we don't add all the jmeJarFiles, this is because e.g. each library depends on core,
+                 * some depend on jme3-terrain etc, but it's the users duty to add the correct libraries.
+                 * If we would add all those each library would have it's one jme3-core, which might even lead
+                 * to build errors then.
+                 */
+                if (dep.name.equals("jme3_xbuf")) {
+                    jmeJarFiles.each{jar ->
+                        if (jar.startsWith("jme3_xbuf")) {
+                            /* Technically you would only need the loaders, not the spatial viewer,
+                             * but users can edit the library if they want to strip off
+                             * the last few possible kilobytes */
+                            resource "jar:nbinst://com.jme3.gde.project.baselibs/libs/$jar!/"
+                        }
+                    }
+                }
+                
                 externalJarFiles.each{jar ->
                     resource "jar:nbinst://com.jme3.gde.project.libraries/libs/${jar}!/"
                 }

+ 6 - 0
docs/libraries.md

@@ -37,3 +37,9 @@ This leads to:
 ```
 
 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.