Well thanks, but I do not even know what Maven or Gradle is. I presume those probably would be build systems, which both could generate the proper groovy-all JAR, right? Systems presumably well-known and used daily by all those who maintain and improve Groovy itself (kudos to you all!), but of no use for us who only use Groovy to build other applications and who need just groovyc to compile, plus standard jar to pack the result and standard java to launch it.
Of course if need be I could learn and use one of them, but it seems sort of at the superfluous side to learn a whole new ecosystem, completely unneeded otherwise, just to create the one sole JAR needed for deployment. Aside of that it seems sort of at the absurd side that each Groovy user does this by himself again, again and again, for each new version? Wouldn't it be infinitely better, more convenient and reasonable to do this task only once at the build site and include the -all JAR to the binary distro, precisely the same way it used to be before 2.5? Incidentally meantime I have searched the maillist too, and found Cédric's recommendation to do without the thing: > On 24 Oct 2019, at 9:51, Cédric Champeau <cedric.champ...@gmail.com> wrote: > Easiest is _not_ to use groovy-all, which is really a convenience to get > _all_ Groovy modules. It's extremely unlikely you need them all, as your > message indicates (you don't need testng, but I'm pretty sure you don't need > groovy-swing either). That, of course, would be a best approach, but I can't see how to ensure that? Actually when I have read the 2.5 release notes for the first time, I presumed that's precisely what happened: that groovy-all is not needed anymore, for the excellent Groovy team, ever on search for improvements, invented some smart magical way to import all the needed JARs automatically without a need to install them at the deployment site manually and placing them to the classpath (presumably, loading them from the Net and caching somehow in case upon the next launch the site happens to be offline, yadda yadda yadda). That would be a help indeed. Alas, when I launched my first 3-based build, the “cannot load app.Application” result proved it is not so :( Thanks again and do please forgive if this sounds a bit rant-like, but this really seems a bit absurd. I could understand if for some reason the Groovy team decided to distribute just the sources and whomever who wants to use Groovy would have to build and pack himself, that would make sense; but given there actually is a binary distro, I can't see why it lacks the -all JAR far as it still is needed for deployment, and leaves it on each user to find a way to build the thing himself :/ All the best, OC > On 18 May 2020, at 15:59, Nelson, Erick <erick.nel...@hdsupply.com> wrote: > > I use Maven to do my build-test-deploy, and I am currently researching > converting to Gradle. > Here is my maven dependency… > > <dependency> > <groupId>org.codehaus.groovy</groupId> > <artifactId>groovy-all</artifactId> > <version>2.5.9</version> > <scope>provided</scope> > <type>pom</type> > </dependency> > > Now, while I do admit I have not tried a build yet with Groovy 3, the Maven > dependency for groovy-all does exist… > > <image001.png> > > > 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 5:43 AM > To: "users@groovy.apache.org <mailto:users@groovy.apache.org>" > <users@groovy.apache.org <mailto:users@groovy.apache.org>> > Subject: How to test and deploy without groovy-all? (was: More Groovy 3 woes) > > Hi there, > > >> On 16 May 2020, at 14:17, OCsite <o...@ocs.cz <mailto:o...@ocs.cz>> wrote: >> First, can you (or anyone) please suggest what to do with my classpath now >> when groovy-all's gone? > > > I still can't see a reasonable solution for that :( All the documentation > I've found so far is > >> http://groovy-lang.org/releasenotes/groovy-2.5.html >> <http://groovy-lang.org/releasenotes/groovy-2.5.html> > which alas does not help at all. Especially I can't see how “simply bumping > the version number” could “be sufficient”? > > Up to 2.4, indeed simply changing the version number did suffice: my build > scripts did select the proper compiler at.../groovy{VERSION}/bin/groovyc, and > to the run script was similarly added > .../Extensions/groovy-all-{VERSION}-indy.jar to the classpath. Worked like a > charm. > > The build still works all right, but how on earth should I run the > application? Without groovy on classpath it just reports that it can't load > theapp.Application class (which is quite understandable, for the class > implementation uses Groovy, and java does not have an access to its JARs at > all, so loading the class fails). > > So far the only way I have found to test was to add a complete contents of > groovy/lib to the classpath. That's darn inconvenient for testing at my side, > and would get extremely inconvenient at the deployment site. > > What's the proper way to launch an application written in Groovy from 2.5 up > on a deployment site (where there's of course no Groovy installation at all)? > Up to 2.4, simple > > java -classpath '...groovy-all-{VERSION}-indy.jar...' app.Application > > did suffice, all what was needed was to place the one groovy-all JAR for each > version of groovy we build with[1] to the Extensions folder, and it worked > perfectly. > > What should I do now instead? I can see I could put all the JARs of all the > groovys we use in there and add them all explicitly to the classpath; but it > will be darn ugly; adding a new groovy release would get rather difficult, > not speaking of switching betwixt different groovy versions for different > applications. > > Thanks a lot, > OC > > [1] for some of our applications we use a fixed groovy version against which > the app was extensively tested, lest we bump into some breaking change in a > newer groovy. Thus, we build and run different applications with different > groovy versions. Up to 2.4, no problem at all, with all the groovy-alls in > the Extensions folder and the proper one in classpath of each run script > worked like a charm.
