I also agree.
The one argument I see for a fat groovy-all, is that it lowers the
hurdle of trying Groovy in your project, if you are in a (e.g. secure)
environment where you cannot use Maven/Gradle to pull in all
dependencies from the internet.
On 22.11.2017 20:22, Leonard Brünings 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>>:
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>>:
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
