Hi there, > On 16 May 2020, at 14:17, OCsite <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 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.
