Gradle has a plugin for XCode anyway (never used it). https://docs.gradle.org/current/userguide/xcode_plugin.html
-- Bob On Mon, May 18, 2020 at 3:38 PM Andy Duncan <a...@adjectivecolournoun.com> wrote: > 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 >>> >> >>
