Thanks! This is one absolutely excellent example of the Java approach to all problems :)
So as I “save bytes, CPU cycles etc.”, namely, so as I do not need to put one groovy-all for each Groovy version we need to support once to each of our servers — which JAR indeed would contain a few parts we won't ever use, at the first look it might seem to be wasting resources — ... ... I am told to embed most of Groovy and other libraries into each application, having thus at the very least as many copies of each JAR on each server as there is separate applications (i.e., tens — definitely more than the number of Groovy versions we shall support concurrently) and also, unless we spend extra time creating some hardlink-based error-prone copy-only-what-changed scheme, also as many of them as there is stored older versions (hundreds). Not speaking of sending unnecessarily all the big stuff over the Net again and again and again installing each new app version (well, unless we put extra effort into some smart and error-and-problem-prone rsync-based installation scheme instead of our current extremely plain, easy and totally reliable scp). Add to the sum the effort needed to resolve the JAR-hell problems, which with this approach definitely will occur sooner or later (most probably sooner). That all, of course, inevitably causes wasting resources, both human and machine, several orders of magnitude worse than the single, cheap and easy monolithic -all JAR ever could in the worst case imaginable. Well indeed, that's precisely what Java teaches us. Nevertheless, I'd prefer just a slightest bit groovier approach :) OC > On 18 May 2020, at 19:22, Tamás Cservenák <ta...@cservenak.net> wrote: > > 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 <mailto:o...@ocs.cz>> > wrote: > >> On 18 May 2020, at 18:12, Mauro Molinari <mauro...@tiscali.it >> <mailto: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
