Hi Mauro,
I think I can shed some light at where OC is coming from. Basically, if
you have a project with very few dependencies and therefore few JARs, it
is without any doubt convenient to have just a single
groovy-all-<version> JAR: You can check with one glance what Groovy
version you are using, and upgrading to another Groovy version is
deleting or moving away the existing groovy-all JAR and replacing it
with the new one. It does not get any easier than that.
Now if you have an automated build process with dependency resolution,
plus a corresponding fully automated deployment, then all of the above
makes little to no sense. If, like in my case, automatic dependency
resolution is a dream (secure network, no access to any Maven server),
and deployment is only semi-automated, then it is not. Due to no
automatic dependency resolution, I deploy all the Groovy JARs, and those
are quite a lot (I have run into (small) problems since there were two
different Groovy versions deployed in my JAR dir, and I overlooked one
JAR when cleaning up manually).
It is no big deal, but if "all you want to do" is quickly (meaning:
download one JAR and replace in build & (maybe multiple) deployment
dirs) check out a new Groovy version, because you have a million other
things to do (if I had spare time for stuff like that, I would much
rather spend it on refactoring several years old, way-too-dynamic Groovy
code and make it @CompileStatic, improve my core framework, etc), then
the suggestion to set up a Gradle project just for that does sound a bit
absurd (even if it might pay dividend later on - I personally don't like
the fact that Gradle's minimal rebuidl capabilities (the last time I
checked), still seemed to lag quite a bit behind using IntelliJ native
builds) :-)
So while we all understand that Groovy being modular is the what is
required / here to stay, for all non-fully-automated people, asking
where groovy-all went is a very obvious question - and the answer "just
build it yourself" is quite confusing at first glance, since if I can
build it myself, why can't the Groovy project supply it in the first
place* ? G-)
Cheers,
mg
*To which the answer is: Since only your project knows all its
dependencies and can therefore avoid the problems Paul mentioned - but
in a world where Java 8 is still going strong (we are on Java 11, but as
we use Groovy exclusively, I am not sure if we would miss much/anything
if we would still use 8, security issues aside) that is still new
thinking to many people.
On 19/05/2020 09:02, Mauro Molinari wrote:
Il 18/05/20 18:47, OCsite ha scritto:
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".
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. ;-)
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.
"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