Prevent wildcard in Class-Path attribute to be unfolded into the startup script files

plugins

(Christian Geißler) #1

Hello,

I’m currently trying to add all my used .jar files to the Class-Path, in order to use the ‘appication’ and ‘distribution’ plugins. But the problem that I encounter is, that it’s such a long list of .jar files (and I can’t leave some out) that the created .bat file from the plugins can’t be run without telling me, that the provided line in the script is too long.

I found out, that since Java 1.6 you can actually use wildcards to shorten the -cp option a lot.
(see http://docs.oracle.com/javase/6/docs/technotes/tools/windows/classpath.html
->Understanding class path wildcards)

In my case, since all the needed .jar files are located in the same folder, it would boil down to use:

set CLASSPATH=%APP_HOME%\lib*;

in the startup.bat script. If I change/set that manually after running “gradle installDist” it works fine. But when I change the gradle script to:

jar {
manifest {
attributes (‘Implementation-Title’: project.name,
‘Implementation-Version’: ‘0.1’,
‘Main-Class’: ‘Run’,
‘Class-Path’: ‘%APP_HOME%\lib\*’
)
}
}

and run “gradle installDist”, it will generate me the batch file class-path line like this:

CLASSPATH=%APP_HOME%\lib\MyTestProgram.jar;%APP_HOME%\lib\Library1.jar;%APP_HOME%\lib\Library2.jar;%APP_HOME%\lib\Library3.jar;%APP_HOME%\lib\Library4.jar; […] %APP_HOME%\lib\Library50.jar;

This might have to do with the fact, that the actual jar manifest file can’t handle wildcards and therefore it is unwrapped/resolved before put into the manifest file. But it also unwraps this for the .bat file, even though the sourceCompatibility and targetCompatibility are set to 1.8. And it resolves into a .bat file that can’t be run, because the class path string is too long for a windows console. Any ideas on how to resolve this?