groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: Building Groovy
Date Thu, 23 Nov 2017 22:54:25 GMT
All of the above (now below) - plus potentially changing the name of the 
fatjar, should one exist in the future...

(If the "fatjar" just references all the other jars
groovy-umbrella.jar
would imho be a better name.)


On 23.11.2017 18:07, Jochen Theodorou wrote:
> 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