Option 4) Use the Maven Assembly plugin or the Shade plugin to build your own groovy-all Jar file. Or just use https://github.com/gradle/gradle-groovy-all <https://github.com/gradle/gradle-groovy-all>
- Keith > On Dec 17, 2018, at 3:49 AM, Paul Moore <p.f.mo...@gmail.com > <mailto:p.f.mo...@gmail.com>> wrote: > > I use Groovy as a scripting language for small tasks, running on > application servers that do not have very good scripting tools > available, and to which I only have limited access. Prior to Groovy > 2.5, I've used the groovy-all jar as a low-impact, easy to deploy > scripting option. I run scripts as > > java -cp .../groovy-all-2.4.x.jar;. groovy.ui.Main myscript.groovy > > The advantages of this approach are: > > 1. One-off deployment of a single binary file to the server, with all > subsequent script deployments being text files (the actual scripts). > 2. Works with whatever Java is present on the server. > 3. Doesn't need to rely on any particular directory structure on the server. > 4. Doesn't need source code to be held elsewhere (it's a > run-from-source solution rather than a compiled binary). > > Since Groovy 2.5, the -all jar has been discontinued - the release > notes explain why, although the reasons don't really apply to me > (getting something as modern as Java 1.9 on the machines I work with > would be a miracle!) But they don't really offer a good replacement > for my use case. > > What's the best option for a situation like mine? Things I've considered are: > > 1. Deploy the full Groovy lib directory and use "-cp > groovy-2.5.x/lib/*;.". Probably the best option, but either requires > copying the full lib directory around or hard-coding its path (at the > moment, I can just dump a copy of the -all jar in the directory > alongside my script). > 2. Use the full install and the supplied bat file wrapper. As well as > the same problem of hard coded paths/copying directories, I find bat > file wrappers extremely problematic - as bat files don't nest, you > have to remember to say "call groovy.bat ..." when running from a > batch script - which frequently gets forgotten. > 3. Compile my scripts with the needed Groovy jars embedded. This means > every script needs to be deployed as a binary, and source needs > managing. Also minor changes involve a full build-deploy cycle. > > Ideally, I'd like a simple means of creating the old -all jar file. > Even if it comes with warnings and limitations, that would be fine for > me (at least, assuming the limitations aren't any worse than they were > in 2.4.x). However, I'm *not* a Java developer, so unfortunately I > don't know how to translate the comment from the release notes stating > "We also provided a convenience "all" jar by jarjar’ing the core and > "module" jars" into instructions for how I could create the -all jar > file for myself. And the comment "we do provide an "all" pom" doesn't > mean much to me either - I understand it's something to do with maven, > but as I don't use tools like maven,. that's not much help to me... > > If anyone can offer any suggestions, I'd be most grateful. > > Paul
