On Tue, May 19, 2020 at 2:58 AM Corum, Michael <mco...@rgare.com> wrote:
> I’ve noticed that there is a general sense that the majority of the users > don’t need groovy-all. How did that knowledge come about? Was there a > survey that I missed? Is there a place I can go to see the survey > results? (By the way – we depend on it in our projects). > The dropping of support for the "all" jar was the only viable solution to meet the JPMS split package requirements for JDK9+. Otherwise, we certainly would have kept it. The TL;DR version, slightly simplified: If two jars containing the same package, e.g. the non-all jar and the all jar were both on the module path (and one might be there indirectly), the VM may refuse to start. In other scenarios like one on classpath and one on module path, one might load and the other silently ignored and then weird classloader issues arise. Our options were all jar only (forcing all users to always have all modules - basically no modules any more) or no all jar. We didn't like either option but the all pom was our best attempt to minimise the pain for users with access to common build tools. One thing we thought about to reduce the pain for embedded Groovy users was to create an embedded folder in the distro zip with the fat jar (like in 2.4) but not publishing the fat jar to any repo. We worried that someone else might publish it, so never followed through. Perhaps that is still viable. Cheers, Paul. > *Michael Corum* > > VP, Technical Architecture Solutions > > > > *RGA Reinsurance Company* > > *16600 Swingley Ridge Road* > > *Chesterfield, Missouri 6301701706* > > *T* 636.736.7066 > > *www.rgare.com <http://www.rgare.com>* > > > > > > > > *From: *OCsite <o...@ocs.cz> > *Reply-To: *"users@groovy.apache.org" <users@groovy.apache.org> > *Date: *Monday, May 18, 2020 at 11:47 AM > *To: *"users@groovy.apache.org" <users@groovy.apache.org> > *Subject: *Re: How to test and deploy without groovy-all? > > > > External e-mail. Use caution! / Courriel externe. Faites attention! > ------------------------------ > > > > 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 >
