And to be fully lost, there are several ways to be sure that a fatjar can not be used as a module dependencies. By example, - create a module-info with a module name that you can not write in java, use an exotic character like '+' in the module name, it's legal in the classfile [1] but not in the source code. - create a module-info with a required module that doesn't exist like 'requires you_should_not_used_a_fat_jar_as_a_module_dependencies'. obviously, it requires to generate the module-info.class without using javac, but not a big deal with ASM.
enjoy, Rémi [1] https://docs.oracle.com/javase/specs/jvms/se9/html/jvms-4.html#jvms-4.2.3 ----- Mail original ----- > De: "Jochen Theodorou" <blackd...@gmx.org> > À: "dev" <dev@groovy.apache.org> > Envoyé: Jeudi 23 Novembre 2017 18:07:15 > Objet: Re: Building Groovy > So what exactly do we disagree on here? Adding a fatjar? We have one > right now, so adding is beyond the point. Making the fatjar provide a > name for the automatic module naming in JPMS? Changing the fatjar to a > lean jar, that just references all the other jars in a build system and > that cannot do so as automatic module? > > I lost the point of this thread > > Am 23.11.2017 um 12:14 schrieb Cédric Champeau: >> -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 >> <mailto: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 <mailto:pa...@asert.com.au>> >> Datum: 23.11.17 02:43 (GMT+01:00) >> An: dev@groovy.apache.org <mailto: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 >> <mailto: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 >>>> <mailto: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> >>>> <mailto: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> >>>> <mailto: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 >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >>
