If you are doing that then most likely you won't be using the module path either, so we could have groovy-standalone.jar,
with a Automatic-Module-Name of "dont.use.this.jar.for.module.path" to make it really obvious on what the proper usage is.

Am 22.11.2017 um 21:58 schrieb Paul King:
The advantage with the fat jar is the convenience of being able to run Groovy without a dependency management system (Gradle/Maven). Java -jar with just the groovy-all jar is going to get you a long way. Then again, I bet most people who aren't using Gradle/Maven probably just download the distribution. So I see the groovy-all jar as a nice to have but not necessarily essential.

Cheers, Paul.

On Thu, Nov 23, 2017 at 5:22 AM, Leonard Brünings <groovy-dev@bruenings-it.net> wrote:
I agree with Cédric, that is also what I suggested before.

With maven/gradle the usage of groovy-all is currently done out of convenience.

I think most projects would work just as well, if groovy-all would be turned into an
empty jar that just depends on the other jars.

Am 22.11.2017 um 19:41 schrieb Jochen Theodorou:
Of course you arr right, I am more worried about the migration path in combination with the final result.

On 22.11.2017 14:30, Cédric Champeau wrote:
Said differently, if you depend on `groovy-all`, it will _effectively_ bring groovy, groovy-json, groovy-xml, groovy-...

All of those can be proper modules (as long as we fix the split packages). Then if someone else only brings in `groovy` + `groovy-json`, there's no conflict.

2017-11-22 14:29 GMT+01:00 Cédric Champeau <cedric.champeau@gmail.com <mailto:cedric.champeau@gmail.com>>:

    That's precisely what I'm saying: we don't need a fat jar. We need a
    _module_ (Maven/Gradle sense of a module), which brings in the jars
    of the individual modules (JPMS sense). So there's no such think as
    a fat jar anymore, we don't need it.

    2017-11-22 14:26 GMT+01:00 Jochen Theodorou <blackdrag@gmx.org

        Am 22.11.2017 um 11:47 schrieb Cédric Champeau:

            What is the advantage of providing a fat jar, if you can
            have a "virtual" dependency, groovy-all, which brings all
            the others in? There used to be a difference, but now it's
            not that clear.

        How are you going to express dependencies with automatic
        modules? They are automatic, because they lack the information a
        proper module provides and part of that information is the
        dependencies afaik. JPMS != maven.

        If you want groovy-all to bring in all the dependencies, then
        basically it is an almost empty jar with dependencies and the
        dependencies are the real modules. the fat-jar itself cannot
        provide any packages those dependencies to provide, otherwise
        you have conflicts. The empty groovy-all-approach is something
        we could go for in maven too of course. But its is not a fatjar
        then ;)

        bye Jochen