I can only comment on our experience: - For most of our projects simply replacing groovy-all with the core groovy module has worked fine as most of our projects don't (didn't) make use of the classes that are not present in the core groovy module. - For the projects that did need missing classes we simply add the needed groovy-* modules. We've never had to add more that two or three other modules and it is almost always just groovy-json and/or groovy-xml - If you _really_ need the entire contents of groovy/lib on the classpath you can try building your own groovy-all jar file. There are instructions for doing this with 2.5.x [1], but it should be possible to do the same for 3.x
I am not sure of your use case, but we've never even come close to needing everything from groovy/lib on the classpath. I hope that gives you some ideas. - Keith 1. https://github.com/gradle/gradle-groovy-all > On May 18, 2020, at 8:43 AM, OCsite <o...@ocs.cz> wrote: > > 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 > the app.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.
