groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <fo...@univ-mlv.fr>
Subject Re: Building Groovy
Date Thu, 23 Nov 2017 19:50:33 GMT
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" <blackdrag@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 <mgbiz@arscreat.com
>> <mailto:mgbiz@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 <paulk@asert.com.au <mailto:paulk@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 <mgbiz@arscreat.com
>>     <mailto:mgbiz@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-dev@bruenings-it.net
>>>>         <mailto: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>
>>>>                     <mailto: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 <mailto:blackdrag@gmx.org>
>>>>                         <mailto:blackdrag@gmx.org
>>>>                     <mailto: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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>> 
>> 

Mime
View raw message