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
