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 <[email protected]> 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 < > [email protected]> 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 <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> 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 <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> >>>> >>>> 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 >>>> >>>> >>>> >>>> >>> >> > > >
