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.
2017-11-22 11:45 GMT+01:00 Jochen Theodorou <blackd...@gmx.org>: > > > Am 22.11.2017 um 10:09 schrieb Cédric Champeau: > >> To me it's very clear that Groovy.next is indy only, so all the >> discussions we have about module names or call site caching are solved. >> > > for the transition time from Groovy not as module and Groovy as module we > require a discussion. Not about the indy versions, but about the fatjar. > Unless my arguments before are good enough and we use different names for > the fatjar and the proper module jars. > > Btw, In my eyes there is zero advantage for Groovy as module. The step is > only required to not be at disadvantage, or even being ruled out as > possibility. Of course the bigger required breaking changes may have the > same effect > > bye Jochen >
