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 <[email protected]>: > 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 <[email protected]>: > >> >> >> 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 >> > >
