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
