From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

Found the following comment on a gist which proves to be as close to simply setting a flag <https://gist.github.com/jlmelville/2bfe9277e9e2c0ff79b6?permalink_comment_id=3453639#gistcomment-3453639>

Even easier:
```startScripts {
    classpath = files('*')
}```


Btw. that's from the `application` plugin (which automatically applies the `distribution` plugin)
The `distribution` plugin is just responsible for creating the archives.

Hmm but how would that setting take into account that JARs are inside a `lib` dir?

And of course you have to keep in mind that the wildcard version is semantically different.
As now you get an arbitrary order on the classpath.
With the explicit jars it is exactly the order defined in the build script which most probably is the reason that tactic is used.

But as long as you make sure that no class is in multiple jars in that directory, behavior should be the same.

&gt; Hmm but how would that setting take into account that JARs are inside a `lib` dir?
It is a relative file and relative files are for that classpath resolved relative to the `lib` directory automatically.
If you have a `foo.jar` then it is put in the distribution in `lib` and `lib/foo.jar` added to the classpath.
If you have `*` then `lib/*` is taken.

I use that snippet myself in some cases, so I know it works. :slightly_smiling_face:

I don’t know about that assumption on order. I suppose right now the order is given by the resolution result in the configuration which may or may not depend on definition order. wildcard should give you alphabetical order in all platforms at the very least. Granted, alphabetical order might break classloading if you really wanted Z before A 

It does depend on definition order.
That is crucial for some cases.
For example if you have the old JMockit versions with the own JUnit runner class that needs to come first in the classpath so that JMockit gets initialized automatically and similar things.

But optimally you have each class only in one jar anyway and then it shouldn't matter indeed. Just a point to keep in mind. :slightly_smiling_face:

What makes you think it will be alphabetical?

<https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html|https://docs.oracle.com/javase/8/docs/technotes/tools/windows/classpath.html>
&gt; The order in which the JAR files in a directory are enumerated in the expanded class path is not specified and may vary from platform to platform and even from moment to moment on the same machine.

readdir/FindFirstFile/etc. aren't inherently ordered. `ls`/`dir`/… are only in alphabetical order because they are written to apply additional sorting, but Java doesn't use the shell commands when expanding wildcards