-1 for adding a fat jar, whatever it is. I sincerely doubt a lot of people use this directly with `java -jar ...`. Either you use the distribution, and we would setup the classpath for you, or you use a build tool, and it's also done for you. And I doubt large companies without access to internet don't use build tools. We have quite evidence of the contrary (they tend to use internal repositories).
2017-11-23 12:08 GMT+01:00 mg <mg...@arscreat.com>: > I was thinking the same. Without being all for changing the name, maybe: > groovy-single.jar > groovy-fat.jar > groovy-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 >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> >> >
