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).
Michael Corum VP, Technical Architecture Solutions RGA Reinsurance Company 16600 Swingley Ridge Road Chesterfield, Missouri 6301701706 T 636.736.7066 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<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
