Well, one (most probably and hopefully) last question in this thread. It's probably pretty stupid and (ii)'s probably the self-evident answer, but after the previous debate, I do not quite trust my intuition with using JARs anymore :)
With the 4.0 snapshot which I have used so far, the classpath contents was simply groovy-4.0.0_S/lib/*.jar. That was easy. Now with 3.0.4 I wonder: since we use indy (and we compile all our sources with the --indy switch), groovy-3.0.4/indy/*.jar seems to be in order, but I've happened to notice the other non-groovy JARs from lib aren't linked into this folder at all. So ... what's the best way to solve that? (i) copy to the deployment site and classpath only the groovy-3.0.4/indy contents. I have actually tried and seems to work... so far. But, might it lead to a crash due to a class not found in future/when some user tries a functionality we haven't ourselves? (ii) first hard-link all the JARs from groovy-3.0.4/indy whose names do not start with “groovy” to groovy-3.0.4/indy, and then do (i). Seems pretty easy, but won't it bring any kind of havoc? Might not there be some kind of clash? (iii) create a script which would copy to server and create the classpath with groovy-3.0.4/indy/*.jar plus (with extended glob) lib/*.jar~lib/groovy*, or something like that? What's the proper and least-dangerous way to do that? So that it works properly Java 8+ anywhere? Thanks, OC > On 20. 5. 2020, at 10:19 PM, MG <mg...@arscreat.com> wrote: > > 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 >> >
