Paul, I guess I should definitely refrain from further debating this until I actually learn the darned JMS stuff (which won't happen anytime soon, given we stick with Java 8, and will for some time to come).
> Well, suppose your project used Groovy and Spock. Perhaps you chose the all > jar and Spock has a dependency on the non-all jar? I'd say the module concept went heel over the head somehow. In my opinion, both my project and Spock should simply reference the classes needed, nothing more[1], nothing less, and runtime, these classes should come from either all-jar or separate small jars or whatever else, depending on what's chosen to be used for the deployment and put into the classpath. Self-evidently it does not work like that anymore. Quadruple ick :/ Thanks and all the best, OC [1] in a purely hypothetical better world than the Java ecosystem actually is, along with the version built against, which coupled with the information of inter-version compatibility stored in frameworks would allow the system either to choose the proper library version to load automatically, or report reliably at launch-time that it is not possible. Alas, that approach, far as I know that is, is impossible with JARs, for there's no information of the inter-version compatibility at all, so the point is moot. > On 19 May 2020, at 13:32, Paul King <pa...@asert.com.au> wrote: > > > On Tue, May 19, 2020 at 8:32 PM OCsite <o...@ocs.cz <mailto:o...@ocs.cz>> > wrote: > Paul, > >> On 19 May 2020, at 7:09, Paul King <pa...@asert.com.au >> <mailto: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? > > Well, suppose your project used Groovy and Spock. Perhaps you chose the all > jar and Spock has a dependency on the non-all jar? >> 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?!? > > It could be a transitive dependency. And yes, JDK9 was quite some work for > many projects. E.g.: > https://github.com/google/flogger/issues/22 > <https://github.com/google/flogger/issues/22> > >> 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 :- > > If it never gets in a repo, I would say the risk is low. If anyone ever puts > it in a repo (without embedding under a different package name) then all bets > would be off. > > Cheers, Paul. > > > 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 >> >
