Paul, > On 19 May 2020, at 7:09, Paul King <pa...@asert.com.au> wrote: > On Tue, May 19, 2020 at 2:58 AM Corum, Michael <mco...@rgare.com > <mailto:mco...@rgare.com>> wrote: > > 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. .... Our > options were all jar only (forcing all users to always have all modules - > basically no modules any more) or no all jar. ...
Well I know next-to-nothing of Java modules — at the moment, we need to be able to run with Java 8, so we can't use the thing even should we want to, which I doubt —, so my question is probably über-stupid and based only on my massive ignorance of that stuff, but anyway: how on earth could a groovy/embedded/groovy-all.jar (or any other JAR from any other directory not explicitly used in the project) ever get into there unwanted, unless the user intentionally adds its path to --module-path? > 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. Well again I freely admit I do not understand the stuff at all, but still, I can't see that a sole publication of a JAR could ever break projects which do not explicitly use it — otherwise, since anybody can (and does) publish nearly anything, no project ever would work Java 9+ anymore?!? > Perhaps that is still viable. From my POV it would be the easiest way for all — simply to add embedded/groovy-all.jar to the binary distro, nothing more, nothing less. Is there really any danger that such a JAR would get amongst the other modules unintentionally and unwanted?!? Again, I do apologise for my massive ignorance, but I really can't see how :-O Thanks, OC > From: OCsite <o...@ocs.cz <mailto:o...@ocs.cz>> > Reply-To: "users@groovy.apache.org <mailto:users@groovy.apache.org>" > <users@groovy.apache.org <mailto:users@groovy.apache.org>> > Date: Monday, May 18, 2020 at 11:47 AM > To: "users@groovy.apache.org <mailto:users@groovy.apache.org>" > <users@groovy.apache.org <mailto: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 >
