On 19.05.20 03:53, OCsite wrote:
Well, thanks, I'll check the thing, though at the first look it rather seems to be a tool for a Gradle project owner who wants to move his projects into Xcode. Me, I'm precisely the opposite case — I've got Xcode projects which I /possibly might/ want to move into Gradle.
I think you need to explain your deployment situation a bit more. Just some rough numbers... to how many computers do you deploy and how many applications? All Mac?
If at all. I still can't see any advantage it would bring to me. It would automatically maintain dependencies, which is something I have never really needed (at least, not until groovy-all disappeared).
there have been afaik 2 main reasons to remove groovy-all... (1) Java module system (JMS). To use Groovy as automatic module we have to make Groovy JMS-ready. We did that in code in some places, but also by providing an automated module name. The problem is no two modules can share the same packages. At the same time the dependency on the module name is part of the Java code now. So if you make one library that depends on groovy-all and one that depends on groovy-core you are screwed. You would have to start patching modules, to supply an alternate module-info.class and many other things, that basically do not allow you to deploy the original version of the library in any way anymore. (2) People were asking for a smaller groovy jar for years. That is not a new request, which actually tends not to come up on the list as often, but more on conferences and when talking with people privately. But in general the trend goes more to lean libraries and a several MB big lib like Groovy does not make a good figure here. As I understood it, you care not so much about these points. I assume you do not plan to switch to JMS in the next years at all (the command line is pure terror if you do not keep the conventions they invented are totally orthogonal to what people commonly use) for example.
Besides, I wonder how reliably it could in principle work. Most of the JAR-hell problems we have encountered happened when there were more versions of the same library and some of them did work OK, some of them did not: for example, having added Fop support, we had to remove xmlgraphics-commons-2.3.jar which we used before without any problem, and had to switch back to xmlgraphics-commons-1.5.jar, which works OK with the Fop thing, whilst 2.3 does not[1]. I /do/ wonder whether Gradle or any other auto-dependency manager /could ever/automate properly and without problems /this/? Is there such kind of information anywhere for the manager to do such decisions reliably?
I am not 100% sure what you mean with "this". What you can do in Gradle is to change the dependency resolution to exclude dependencies, to force certain versions of dependencies, to fail the build if two version of the same dependency are to be used (does not work for for example groovy-all and groovy-core being used at the same time, since their name is different) Right now you manage dependencies manually I assume. bye Jochen
