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 <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
