distZip in subproject seems to be generating scripts that have incorrect CLASSPATH entries due to extra directory

Old Forum Archive Bugs
1

Hi there,

I’ve been using the application plugin and generating distributions using distZip. I’m using a standard directory layout (main/src/java) with nothing particularly special, you can see the build.gradle here:

https://github.com/andrewhayden/archive-patcher/blob/master/tools/transformer/build.gradle

The project is a subproject, When I build dist from the root, the resulting ZIP archives contain incorrect logic for constructing the classpath. Instead of APP_HOME/lib/.jar, I see entries of the form APP_HOME/bin/lib/.jar, which are wrong.

Actual directory layout (result of extracting distribution into /tmp):
/tmp/archivepatcher-tools-transformer-1.0/bin/tools/transformer
/tmp/archivepatcher-tools-transformer-1.0/lib/archivepatcher-tools-transformer-1.0.jar
(and more JARs, omitted for brevity)

Notice the extraneous “tools” directory in the bin path that is not present in the lib path. This almost certainly has crept in from the subdirectory in which the subproject resides, in my case tools/transformer.

The wrapper script generates a CLASSPATH that looks like this:
/tmp/archivepatcher-tools-transformer-1.0/bin/lib/archivepatcher-tools-transformer-1.0.jar:

Notice that the CLASSPATH has “/bin/lib” instead of simply “/lib” in the path to the JAR.

It looks like the wrapper script contains logic to find the program’s parent directory and uses that as APP_HOME, which is the basis for constructing the CLASSPATH. In this case because the parent directory is “/tmp/archivepatcher-tools-transformer-1.0/bin/tools/transformer” instead of just “/tmp/archivepatcher-tools-transformer-1.0/bin/transformer” (note the missing “tools”), we end up with that extra “bin” hanging off the end. Whoops!

I don’t think I’ve done anything particularly weird in my build files, but the github link above shows everything. This is broken in Gradle 2.9 and Gradle 2.10. I haven’t tried Gradle 2.11-RC3 but have no reason from the changelog to think that it is fixed there,

Perhaps I’ve done something wrong somewhere? This should “just work”, without any modifications by me, I would think.

2

The issue here is the embedded “/” characters in the project names. I’m assuming this was not done on purpose, but maybe was a misunderstanding of how the multi-project set up works. In settings.gradle, you should have something like this:

include 'core'
include 'examples'
...
include ':tools:transformer'

Notice the “:” instead of “/”. This tells gradle to create a project named “transformer” in the subproject “tools” (and expects a corresponding directory structure as the convention). With “:tools/transformer”, it creates a project named “tools/transformer” under the root project. I think the “/” has been working for you up to this point for all of the wrong reasons because the directories just happen to line up properly.

For the application plugin, it’s creating a script named after the project (tools/transformer) and because of the “/”, it is actually creating the script in a “tools” subdirectory. I bet if you change the project names to remove the “/” characters it will work properly.