You misread or misinterpreted what i said: i never said "I am told to *embed* most of Groovy and other libraries into *each application".*
I was talking about* builds.* *T* On Mon, May 18, 2020, 20:16 OCsite <o...@ocs.cz> wrote: > 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> 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 >> > >
