To write and maintain my own launch script takes about one thousandth time and effort as compared with learning a whole new ecosystem which I do not need at all (well, perhaps now for the first time and for the one and one sole thing, i.e., creating my own groovy-all, which should be part of the distro).
IMHO Learning Gradle to build a simple Groovy project does not
imply learning "a whole ecosystem".
If you embed all libraries and each your app is a multigigabyte monster, then of course. If I embedded complete groovy/lib to my application, I would not need groovy-all in my Extension folder either; but that would be one terribly wrong engineering, as detailed above.By the way: by using Gradle I think I've never used groovy-all even when on 2.4.x. Never needed to bring it all with my application. ;-)
"multigigabyte monster" is a hyperbole ;-)
Some tens of megabytes for complex webapps with ~120 dependencies
(either direct or transitive) is reality. I don't think this is a
huge problem nowadays, it of course depends on what you're
targeting.
In any case I can hardly follow you. You say you don't want to embed all your dependencies into a fat JAR or into a lib directory for each of your applications, because you have many dependencies and you don't want to duplicate them among your applications. But at the same time you're complaining because you'll now need I guess 2 or 3 small Groovy JARs rather than one fat JAR. It sounds like a contradiction to me. I can't understand what is stopping you from treating Groovy just like any other dependency of your project, like the mentioned fop, or xmlgraphics-commons, or any logging library you may use, or a JDBC driver, or whatsoever...
If the problem is "how do I know which Groovy JARs I need",
perhaps you may again use Gradle to build the mentioned ZIP file,
then look into the lib directory of that JAR and you'll discover
all the JARs (including Groovy ones) that your application
actually depends on, either directly or transitively. Then you can
take what you need to adjust your deploy and share JARs among all
your applications if you need to follow this route.
Mauro
