Hi, If you're bundling up Grooby applications for deployment on to servers,, I would echo what others have said and look into Gradle, along with the Shadow plugin [1] . Having lived through the age of Ant and committing all of the binary dependencies in my projects to source control, having a build system that can bootstrap itself from nothing, manage all of the dependencies, _and_ package only the classes my project actually needs into a single jar still seems a bit like magic!
I've got a project [2] implementing AWS Lambda functions in Groovy that does substantially the same thing. The functions are packaged up into a single file and deployed to AWS, but the same principle would apply for an executable jar. There's an example of doing that in the Shadow documentation. I don't know how Xcode handles it, but IDEA has very good support for Gradle. It can import the project directly from the build.gradle file, and by default defers to Gradle to do the building, so the result is exactly the same as on a build server. I hope this example helps, it really is so much easier than managing pre-installed dependencies on a build server. Andy [1] https://imperceptiblethoughts.com/shadow/ [2] https://github.com/andyjduncan/serverless-dyndns On Mon, May 18, 2020 at 7:16 PM OCsite <o...@ocs.cz> wrote: > Thanks! This is one absolutely excellent example of the Java approach to > all problems :) > > So as I “save bytes, CPU cycles etc.”, namely, so as I do not need to put > *one* groovy-all for each Groovy version we need to support *once* to > each of our servers — which JAR indeed would contain a few parts we won't > ever use, at the first look it might *seem* to be wasting resources — ... > > ... I am told to *embed* most of Groovy and other libraries into *each* > application, having thus at the very least as many copies of each JAR on > each server as there is separate applications (i.e., *tens* — definitely > more than the number of Groovy versions we shall support concurrently) and > *also*, unless we spend extra time creating some hardlink-based > error-prone copy-only-what-changed scheme, also as many of them as there is > stored older versions (*hundreds*). Not speaking of sending unnecessarily > all the big stuff over the Net again and again and again installing each > new app version (well, unless we put extra effort into some smart and > error-and-problem-prone rsync-based installation scheme instead of our > current extremely plain, easy and totally reliable scp). Add to the sum the > effort needed to resolve the JAR-hell problems, which with this approach > definitely *will* occur sooner or later (most probably sooner). > > That all, of course, inevitably causes wasting resources, both human and > machine, several orders of magnitude worse than the single, cheap and easy > monolithic -all JAR ever could in the worst case imaginable. > > Well indeed, that's precisely what Java teaches us. Nevertheless, I'd > prefer just a slightest bit groovier approach :) > OC > > On 18 May 2020, at 19:22, Tamás Cservenák <ta...@cservenak.net> wrote: > > The lack of groovy-all is just on par with literally everything else > "monolithic". You don't have spring-all, jetty-all, jackson-all, do you? > > Nowadays developers use tools to maintain their dependencies (and > transitive ones). Basically no need for a "monolithic" ALL that you for > sure does not use 100% of it, just pick what you need: less bytes, less CPU > cycles, less CO2 :) > > OTOH, you DO have _distributions_, binary blobs that are not build > artifacts (JARs so to say), but are laid in specific was that should make > them easy to integrate into any "custom" scripted build environment (Jetty > is even encouraging their layout for prod). It could serve for your case a > "groovy all", no? (as it does have all) > > Maybe what you need is to integrate Groovy Distribution into your custom > build scripts (as I understand, you do have some custom build environment, > not some "common build too"), and not "just JAR"s? > > My 5 cents, > T > > On Mon, May 18, 2020 at 6:47 PM OCsite <o...@ocs.cz> wrote: > >> >> 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 >> > >
