groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Søren Berg Glasius <>
Subject Re: What is the best replacement for running scripts using groovy-all?
Date Wed, 19 Dec 2018 20:00:33 GMT
Hi Paul,

This is where The @Grab anotation comes in handy:

It wil automatically download your dependencies and it works in Groovy
scripts too.

Best regards / Med venlig hilsen,
Søren Berg Glasius

Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.

On Wed, 19 Dec 2018 at 20:27, Paul Moore <> wrote:

> On Wed, 19 Dec 2018 at 08:56, Paul Moore <> wrote:
> >
> > On Wed, 19 Dec 2018 at 00:03, Keith Suderman <> wrote:
> > >
> > > Option 4) Use the Maven Assembly plugin or the Shade plugin to build
> your own groovy-all Jar file.  Or just use
> >
> > Thanks. Are there any "beginner guide" style instructions on how to
> > use the Maven Assembly plugin or Shade plugin that you can point me
> > to? As I say, I don't use Maven, so the instructions for the plugins
> > use a lot of terms and ideas I'm not familiar with. I can (and
> > probably will!) use the gradle-groovy-all but I'd like to learn a bit
> > more about the Java ecosystem (I'm mostly a Python programmer, but I
> > use Groovy as an alternative for environments where JVM-based tools
> > are a better fit than Python-based ones). I find that starting Groovy
> > *without* a Java/JVM background, there's a lot of assumed knowledge
> > it's quite hard to pick up (unless you're willing to learn Java at the
> > same time ;-))
> I've been digging around with this some more, and I've come to the
> conclusion that it's not that important to me in fact to have a single
> groovy-all jar for my deployment. But what I *do* need is a simple way
> to collect together everything I need to run my script(s) and ship
> them to the target machine(s). So my starting point is one or more
> .groovy files. I do *not* want to compile these - I want to ship the
> source script to the server, so that minor changes can be made in
> place using just a text editor. And with them, I want a directory full
> of supporting jar files.
> Having created and tested the scripts, I need to collect together all
> of the jar files I used to run them. Obviously, the first thing I need
> is the Groovy jars. Ideally I'd try to strip out unneeded jars (my
> code is to be run on a server with no GUI, so I suspect the
> groovy-swing jar could be skipped, for example). But that's probably
> way more trouble than it's worth, so I'm OK with skipping that step.
> Other dependencies, I've tended to collect from various places (for
> development, I can use @Grab annotations in the source, but my server
> doesn't have Internet access, so that won't work for the deployed
> version).
> From what I gather with Java projects, dependencies get managed by a
> tool like Maven or Gradle or by the IDE. But it's very hard for me to
> understand the documentation for these tools, as they are typically
> looking at the problem from the point of view of "compile and build a
> binary from the sources" rather than "collect dependencies into one
> place, but don't compile anything". One problem I'm struggling with is
> that with my background, what I'm trying to do is "obviously" the
> right approach, but I get the feeling that it's very different from
> the Java/Groovy way of doing things, so I keep missing the point of
> people's explanations.
> Essentially, what I want is a project structure like this:
> MyProject
>     script1.groovy
>     script2.groovy
>     script3.groovy
>     script4.groovy
>     dependencies.txt
>     target
>         lib
> dependencies.txt can be anything but what it contains should be a list
> of dependencies - something like
> org.codehaus.groovy:groovy-all:pom:2.5.4
> javax.mail:mail:jar:1.4.4
> org.apache.commons:commons-csv:jar:1.6
> Running "some command" should then copy all the jars needed (based on
> those dependencies) to target/lib. Ideally, copy *.groovy to target as
> well, so I can just zip up the target directory, ship it to the
> destination machine, where I can unzip it and run it with whatever JVM
> is present there.
> Am I missing something fundamental which makes this impossible to
> achieve with Java, or is it just that my Google skills have failed me?
> Or is it that Java projects simply aren't normally of this form?
> Paul

View raw message