On Tue, May 19, 2020 at 8:32 PM OCsite <o...@ocs.cz> wrote: > 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> 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 > 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> >> *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 >> > >
