I was thinking the same. Without being all for changing the name, maybe:groovy-single.jargroovy-fat.jargroovy-the-one.jar(or more fluent: the-one-groovy.jar ;-) )? -------- Ursprüngliche Nachricht --------Von: Paul King <pa...@asert.com.au> Datum: 23.11.17 02:43 (GMT+01:00) An: dev@groovy.apache.org Betreff: Re: Building Groovy The issue we sometimes get with names like "standalone" (and even "all") is that sometimes folks assume that means with all optional dependencies embedded like ivy, commons-cli, junit etc. I am not saying that "standalone" is any worse than "all", just a point to keep in mind when picking names ... Cheers, Paul.
On Thu, Nov 23, 2017 at 8:53 AM, MG <mg...@arscreat.com> wrote: I like groovy-standalone.jar as a name (clearer than "all"). Alas changing names breaks all internet guides/posts/etc preceeding the name change, so one has to be careful with things like this... On 22.11.2017 23:33, Leonard Brünings wrote: 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-...@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.champ...@gmail.com <mailto:cedric.champ...@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 <blackd...@gmx.org <mailto:blackd...@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