Hi Paul, This is where The @Grab anotation comes in handy: http://docs.groovy-lang.org/latest/html/documentation/grape.html
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 <p.f.mo...@gmail.com> wrote: > On Wed, 19 Dec 2018 at 08:56, Paul Moore <p.f.mo...@gmail.com> wrote: > > > > On Wed, 19 Dec 2018 at 00:03, Keith Suderman <suder...@anc.org> wrote: > > > > > > 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 > > > > 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 >
