The lack of groovy-all is just on par with literally everything else "monolithic". You don't have spring-all, jetty-all, jackson-all, do you?
Nowadays developers use tools to maintain their dependencies (and transitive ones). Basically no need for a "monolithic" ALL that you for sure does not use 100% of it, just pick what you need: less bytes, less CPU cycles, less CO2 :) OTOH, you DO have _distributions_, binary blobs that are not build artifacts (JARs so to say), but are laid in specific was that should make them easy to integrate into any "custom" scripted build environment (Jetty is even encouraging their layout for prod). It could serve for your case a "groovy all", no? (as it does have all) Maybe what you need is to integrate Groovy Distribution into your custom build scripts (as I understand, you do have some custom build environment, not some "common build too"), and not "just JAR"s? My 5 cents, T On Mon, May 18, 2020 at 6:47 PM OCsite <o...@ocs.cz> wrote: > > On 18 May 2020, at 18:12, Mauro Molinari <mauro...@tiscali.it> wrote: > > Il 18/05/20 17:48, OCsite ha scritto: > > (Actually I can't imagine the Maven/Gradle workflow to be considerably > different: the principle of creating the application package and installing > it plus all the JARs needed to the server and launching it there with > proper classpath is completely independent on the toolchain, is is not?) > > If I understand it well, the main difference is: Maven/Gradle also provide > for dependency management. > > I can't see how. Embedding all the dependencies is not reasonable: that > way, your application gets monstrously big, and you either waste both the > bandwidth installing and the space on all the servers, or you need to have > a smart installation script, probably rsync-based. Still, even with this, > you won't be able to easily keep old application versions (again, unless > you make some smart tools based on hardlinks), etc. > > Embedding makes sense where the thing does not change often. It very > definitely makes an excellent sense to embed all the Groovy JARs into > groovy-all, for there's a small number of separate Groovy versions to keep > for a particular server. It would be completely absurd to embed groovy (and > other libraries, which change even seldom than Groovy) into the > application, whose new version is deployed pretty often. > > Aside of that, there's sharing of resources: whilst we do need for > application A to use Groovy 2.4.17 and B to use 3.0.3, there's also C, D > and E, which all use 2.4.17, and F and G which both use 3.0.3. Aside of > that, *all* the application share the WebObjects and WOnder libraries and > a number of other JARs. Embedding them all into each the application would > be a nonsense. > > If your only dependency is Groovy, you're very lucky. Usually you'll > depend on other modules, probably dozens of them: thinking of handling them > manually as you do produces the so called "JAR hell". > > Actually JAR hell is not caused by manual handling of libraries, but by > the completely stupid Java JAR design. Given the Sun engineers already had > had an experience with an infinitely better OpenStep, which they had > co-designed with NeXT and whose frameworks do not sport this problem, it is > very sad; and precisely the same applies to the language itself: how on > earth can somebody who already experienced the elegance and power of > Objective C invent an übercrap like Java?!? Anyway, I am digressing again, > sorry for that :( > > Anyway, with groovy-all there's no JAR-hell at least far as Groovy itself > is concerned. Removing groovy-all brings it, or at the very least its > potential, to Groovy itself too :( > > To build project B to get an application B.woa with 3.0.3 groovyc, and to > make sure at the deployment site that this application, when launched, gets > all the proper groovy 3.0.3 libraries. This seems unnecessarily complicated > compared with the above: either I am forced to create my own > groovy-all-3.0.3-indy.jar myself (and then 3.0.4 again, etc. etc.), or I > have to copy lots of JARs to the server and to the classpath separately. > Ick. > > What I am asking for is a reasonable way to do the B part, so that it is > not unnecessarily much more complicated than A. > > With Gradle, applying the "application plugin" will let you build a fat > JAR or rather a ZIP file containing your application code and all of its > dependency JARs > > Which is precisely what you *do not* want to do, at least, not if you use > a big number of big libraries, as detailed above. > > plus the scripts needed to run your application under different operating > systems. Substantially for free. > > 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). > > So you can easily copy your JAR or your ZIP file from one environment to > the other and start your application, being sure it will run properly.- > > Creating so either hundreds of copies of all the libraries on each the > server, which would be patently absurd (not speaking of the bandwidth > copying them again and again and again completely unnecessarily upon each > new app version), or having to prepare a pretty smart hardlink-based > environment for keeping old copies, which would be possible, but again > pretty difficult and time- and effort-consuming, with a danger of errors. > > Whilst I can easily integrate groovyc and the jar tool into Xcode's build > system to do what's needed, I don't think it would be possible to do that > with whole Maven/Gradle ecosystem. Or would it? How? > > I don't know Xcode, sorry. However Gradle, by itself, is IDE agnostic. It > can integrate with some IDEs (like Eclipse or IDEA, perhaps others?), but > you may just use it on its own on the command line. > > Perhaps so, but what would I get, as compared with launching groovyc > directly? Gradle can't be used to keep track of project changes — IDE does > that itself. And embedding all the libraries into the application, which I > would get for free, is definitely what I do not want, as detailed above > (besides, *if* I wanted it, I would simply mark those libraries as > resources in Xcode and would get that for free too). > > That's my very point: why on earth this big fat JAR is not anymore part of > the distro, if it is that easy for Groovy's own build (which itself would > be presumably Maven- or Gradle-based)?!? Forcing instead to do it us end > users for whom it is *far* from that easy :( > > Because, as I said, for the vast majority of Groovy consumers nowadays > that fat JAR does not make sense any more. For the few people that still > want it, they can easily build it by themselves. I think this was the > rationale behind this choice. > > For one, I don't want it, but far as I can say, I need it; and I can't see > any easy way to build it, unless I learn a whole new build system which I > do not need for anything else. > > 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. > > Thanks, > OC >
