Again thanks, but this seems sort of at the dangerous side. Correct me please if I am wrong, but I understand JVM loads the classes on-demand when they are needed, not all at the launch time.
That would mean that a well- but not completely-tested application (and we all know it is just not possible to test completely!) still could crash when a user tries something different from all the testers (and we all know users do that!) due to some JAR not available at the deployment site. Or am I wrong and there is some magic which would prevent this scenario? Thanks! OC > On 18 May 2020, at 16:16, Keith Suderman <suder...@anc.org> wrote: > > 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 > <https://github.com/gradle/gradle-groovy-all> > >> On May 18, 2020, at 8:43 AM, OCsite <o...@ocs.cz <mailto: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. >
