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

Reply via email to