Re: What is the best replacement for running scripts using groovy-all?

2018-12-20 Thread Mario Garcia
BTW about @Grab, bear in mind that you can tell @Grab where to put/take its
dependencies from:

groovy -Dgrape.root=./lib my_script.groovy

So every project can have its dependencies in the project's structure.

Regards
Mario

El jue., 20 dic. 2018 a las 10:44, Paul Moore ()
escribió:

> I can understand that logic - there are quirks I've hit with the fat
> jar approach, but because I made the fat jar myself, I'm OK with just
> assuming it's a weirdness that I can either live with or investigate.
> But if it happened with a supplied jar, I'd feel that I should report
> the problem (even if I could work around it) in case it hit others,
> too. So that's an extra burden on the developers, as you say.
>
> Having an uber jar in the zip distribution would have solved my use
> case. Or even just a recipe in the documentation explaining how to
> build an uber jar for yourself. If the Gradle script I posted here
> earlier is of any help, feel free to use it.
>
> Paul
>
> On Thu, 20 Dec 2018 at 00:44, Paul King  wrote:
> >
> > We don't want to publish a fat jar to maven because it will cause
> problems that we will continually be asked about but perhaps having an uber
> jar within the zip distribution might be something we could look at. I
> suspect over time though that even that could be problematic.
> >
> > On Thu, Dec 20, 2018 at 8:46 AM MG  wrote:
> >>
> >> Hi,
> >>
> >> out of curiosity (and because having a fat jar again might be
> >> conventient at some point in the future in my work environment (also no
> >> internet access)):
> >>
> >> This solution proposed by Keith does not work
> >> https://github.com/gradle/gradle-groovy-all
> >> ?
> >>
> >> Cheers,
> >> mg
> >>
> >>
> >>
> >> Am 19.12.2018 um 23:33 schrieb Paul Moore:
> >> > On Wed, 19 Dec 2018 at 21:23, James Kleeh 
> wrote:
> >> >> Paul,
> >> >>
> >> >> The best solution is to use Maven or Gradle to create an all-in-one
> (fat) jar that you can ship and run with java -jar
> >> >>
> >> >> Gradle has a shadow plugin and Maven has a shade plugin to do just
> that.
> >> > Thanks. I'd come to the conclusion that Gradle was likely the solution
> >> > I should be looking at, and I've spent the evening trying to set up a
> >> > basic Gradle script that does what I want. After a lot of
> >> > experimentation, I came up with the following, which seems to do what
> >> > I want:
> >> >
> >> > -- start build.gradle --
> >> >
> >> > version = "0.1"
> >> >
> >> > configurations {
> >> >  deploy
> >> > }
> >> >
> >> > dependencies {
> >> >  deploy 'org.codehaus.groovy:groovy-all:2.5.4'
> >> > }
> >> >
> >> > repositories {
> >> >  jcenter()
> >> > }
> >> >
> >> > task copyDeps(type:Copy, group: "Custom", description: "Copies project
> >> > dependencies") {
> >> >  from configurations.deploy.collect { it.absolutePath }
> >> >  into "dest/lib"
> >> > }
> >> >
> >> > task copy(type: Copy, group: "Custom", description: "Copies sources to
> >> > the dest directory") {
> >> >  from "src"
> >> >  include "*.groovy"
> >> >  into "dest"
> >> > }
> >> >
> >> > task deploy(type:Zip, group: "Custom", description: "Build a
> deployment zip") {
> >> >  dependsOn copyDeps
> >> >  dependsOn copy
> >> >  from "dest"
> >> >  setArchiveName "${project.name}-${project.version}.zip"
> >> > }
> >> >
> >> > -- end build.gradle --
> >> >
> >> > It doesn't create a fat jar yet, but I can look into setting that up.
> >> > The various existing plugins seem to be dependent upon the
> >> > infrastructure set up by the java plugin, which I don't really
> >> > understand (or need, as far as I can tell) so they may not be of much
> >> > help. But I'm not sure what I need to do yet to write my own.
> >> > Something simple like
> >> >
> >> > task customFatJar(type: Jar) {
> >> >  dependsOn copyDeps
> >> >  baseName = 'all-in-one-jar'
> >> >  from "dest/lib"
> >> > }
> >> >
> >> > gives me an "all-in-one-jar.jar" that contains the dependency jars
> >> > directly included, rather than being unpacked. So there's more I need
> >> > to do here...
> >> >
> >> > Paul
> >> >
> >>
>


Re: What is the best replacement for running scripts using groovy-all?

2018-12-20 Thread Paul Moore
I can understand that logic - there are quirks I've hit with the fat
jar approach, but because I made the fat jar myself, I'm OK with just
assuming it's a weirdness that I can either live with or investigate.
But if it happened with a supplied jar, I'd feel that I should report
the problem (even if I could work around it) in case it hit others,
too. So that's an extra burden on the developers, as you say.

Having an uber jar in the zip distribution would have solved my use
case. Or even just a recipe in the documentation explaining how to
build an uber jar for yourself. If the Gradle script I posted here
earlier is of any help, feel free to use it.

Paul

On Thu, 20 Dec 2018 at 00:44, Paul King  wrote:
>
> We don't want to publish a fat jar to maven because it will cause problems 
> that we will continually be asked about but perhaps having an uber jar within 
> the zip distribution might be something we could look at. I suspect over time 
> though that even that could be problematic.
>
> On Thu, Dec 20, 2018 at 8:46 AM MG  wrote:
>>
>> Hi,
>>
>> out of curiosity (and because having a fat jar again might be
>> conventient at some point in the future in my work environment (also no
>> internet access)):
>>
>> This solution proposed by Keith does not work
>> https://github.com/gradle/gradle-groovy-all
>> ?
>>
>> Cheers,
>> mg
>>
>>
>>
>> Am 19.12.2018 um 23:33 schrieb Paul Moore:
>> > On Wed, 19 Dec 2018 at 21:23, James Kleeh  wrote:
>> >> Paul,
>> >>
>> >> The best solution is to use Maven or Gradle to create an all-in-one (fat) 
>> >> jar that you can ship and run with java -jar
>> >>
>> >> Gradle has a shadow plugin and Maven has a shade plugin to do just that.
>> > Thanks. I'd come to the conclusion that Gradle was likely the solution
>> > I should be looking at, and I've spent the evening trying to set up a
>> > basic Gradle script that does what I want. After a lot of
>> > experimentation, I came up with the following, which seems to do what
>> > I want:
>> >
>> > -- start build.gradle --
>> >
>> > version = "0.1"
>> >
>> > configurations {
>> >  deploy
>> > }
>> >
>> > dependencies {
>> >  deploy 'org.codehaus.groovy:groovy-all:2.5.4'
>> > }
>> >
>> > repositories {
>> >  jcenter()
>> > }
>> >
>> > task copyDeps(type:Copy, group: "Custom", description: "Copies project
>> > dependencies") {
>> >  from configurations.deploy.collect { it.absolutePath }
>> >  into "dest/lib"
>> > }
>> >
>> > task copy(type: Copy, group: "Custom", description: "Copies sources to
>> > the dest directory") {
>> >  from "src"
>> >  include "*.groovy"
>> >  into "dest"
>> > }
>> >
>> > task deploy(type:Zip, group: "Custom", description: "Build a deployment 
>> > zip") {
>> >  dependsOn copyDeps
>> >  dependsOn copy
>> >  from "dest"
>> >  setArchiveName "${project.name}-${project.version}.zip"
>> > }
>> >
>> > -- end build.gradle --
>> >
>> > It doesn't create a fat jar yet, but I can look into setting that up.
>> > The various existing plugins seem to be dependent upon the
>> > infrastructure set up by the java plugin, which I don't really
>> > understand (or need, as far as I can tell) so they may not be of much
>> > help. But I'm not sure what I need to do yet to write my own.
>> > Something simple like
>> >
>> > task customFatJar(type: Jar) {
>> >  dependsOn copyDeps
>> >  baseName = 'all-in-one-jar'
>> >  from "dest/lib"
>> > }
>> >
>> > gives me an "all-in-one-jar.jar" that contains the dependency jars
>> > directly included, rather than being unpacked. So there's more I need
>> > to do here...
>> >
>> > Paul
>> >
>>


Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread Paul King
We don't want to publish a fat jar to maven because it will cause problems
that we will continually be asked about but perhaps having an uber jar
within the zip distribution might be something we could look at. I suspect
over time though that even that could be problematic.

On Thu, Dec 20, 2018 at 8:46 AM MG  wrote:

> Hi,
>
> out of curiosity (and because having a fat jar again might be
> conventient at some point in the future in my work environment (also no
> internet access)):
>
> This solution proposed by Keith does not work
> https://github.com/gradle/gradle-groovy-all
> ?
>
> Cheers,
> mg
>
>
>
> Am 19.12.2018 um 23:33 schrieb Paul Moore:
> > On Wed, 19 Dec 2018 at 21:23, James Kleeh  wrote:
> >> Paul,
> >>
> >> The best solution is to use Maven or Gradle to create an all-in-one
> (fat) jar that you can ship and run with java -jar
> >>
> >> Gradle has a shadow plugin and Maven has a shade plugin to do just that.
> > Thanks. I'd come to the conclusion that Gradle was likely the solution
> > I should be looking at, and I've spent the evening trying to set up a
> > basic Gradle script that does what I want. After a lot of
> > experimentation, I came up with the following, which seems to do what
> > I want:
> >
> > -- start build.gradle --
> >
> > version = "0.1"
> >
> > configurations {
> >  deploy
> > }
> >
> > dependencies {
> >  deploy 'org.codehaus.groovy:groovy-all:2.5.4'
> > }
> >
> > repositories {
> >  jcenter()
> > }
> >
> > task copyDeps(type:Copy, group: "Custom", description: "Copies project
> > dependencies") {
> >  from configurations.deploy.collect { it.absolutePath }
> >  into "dest/lib"
> > }
> >
> > task copy(type: Copy, group: "Custom", description: "Copies sources to
> > the dest directory") {
> >  from "src"
> >  include "*.groovy"
> >  into "dest"
> > }
> >
> > task deploy(type:Zip, group: "Custom", description: "Build a deployment
> zip") {
> >  dependsOn copyDeps
> >  dependsOn copy
> >  from "dest"
> >  setArchiveName "${project.name}-${project.version}.zip"
> > }
> >
> > -- end build.gradle --
> >
> > It doesn't create a fat jar yet, but I can look into setting that up.
> > The various existing plugins seem to be dependent upon the
> > infrastructure set up by the java plugin, which I don't really
> > understand (or need, as far as I can tell) so they may not be of much
> > help. But I'm not sure what I need to do yet to write my own.
> > Something simple like
> >
> > task customFatJar(type: Jar) {
> >  dependsOn copyDeps
> >  baseName = 'all-in-one-jar'
> >  from "dest/lib"
> > }
> >
> > gives me an "all-in-one-jar.jar" that contains the dependency jars
> > directly included, rather than being unpacked. So there's more I need
> > to do here...
> >
> > Paul
> >
>
>


Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread Remko Popma
You may be interested in the Gradle application plugin. This creates a 
distribution zip file with all the dependencies and some starter scripts. 
https://docs.gradle.org/current/userguide/application_plugin.html

The only customization would be to add your custom script to the bin/ directory 
where the starter scripts live. 


Remko.
(Shameless plug) Every java main() method deserves http://picocli.info

> On Dec 20, 2018, at 8:00, Paul Moore  wrote:
> 
>> On Wed, 19 Dec 2018 at 22:46, MG  wrote:
>> 
>> Hi,
>> 
>> out of curiosity (and because having a fat jar again might be
>> conventient at some point in the future in my work environment (also no
>> internet access)):
>> 
>> This solution proposed by Keith does not work
>> https://github.com/gradle/gradle-groovy-all
>> ?
> 
> See https://github.com/gradle/gradle-groovy-all/issues/1
> 
> Basically, yes it does, but only for groovy.ui.GroovyMain (which is
> fine) and they don't support usage for anything other than Gradle's
> purposes and they are looking to discontinue it once Gradle no longer
> needs it (which isn't quite as fine ;-))
> 
> In addition, by not going with that solution, I've learned a lot about
> Gradle and how to use it to solve my problem, which is much better, as
> not only do I have a solution, I also learned something new :-) By the
> way - my Gradle solution also doesn't work for groovy.ui.Console, but
> that's fine as I say above (and it's a chance to learn more, working
> out why :-))
> 
> Paul


Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread Paul Moore
On Wed, 19 Dec 2018 at 22:46, MG  wrote:
>
> Hi,
>
> out of curiosity (and because having a fat jar again might be
> conventient at some point in the future in my work environment (also no
> internet access)):
>
> This solution proposed by Keith does not work
> https://github.com/gradle/gradle-groovy-all
> ?

See https://github.com/gradle/gradle-groovy-all/issues/1

Basically, yes it does, but only for groovy.ui.GroovyMain (which is
fine) and they don't support usage for anything other than Gradle's
purposes and they are looking to discontinue it once Gradle no longer
needs it (which isn't quite as fine ;-))

In addition, by not going with that solution, I've learned a lot about
Gradle and how to use it to solve my problem, which is much better, as
not only do I have a solution, I also learned something new :-) By the
way - my Gradle solution also doesn't work for groovy.ui.Console, but
that's fine as I say above (and it's a chance to learn more, working
out why :-))

Paul


Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread MG

Hi,

out of curiosity (and because having a fat jar again might be 
conventient at some point in the future in my work environment (also no 
internet access)):


This solution proposed by Keith does not work
https://github.com/gradle/gradle-groovy-all
?

Cheers,
mg



Am 19.12.2018 um 23:33 schrieb Paul Moore:

On Wed, 19 Dec 2018 at 21:23, James Kleeh  wrote:

Paul,

The best solution is to use Maven or Gradle to create an all-in-one (fat) jar 
that you can ship and run with java -jar

Gradle has a shadow plugin and Maven has a shade plugin to do just that.

Thanks. I'd come to the conclusion that Gradle was likely the solution
I should be looking at, and I've spent the evening trying to set up a
basic Gradle script that does what I want. After a lot of
experimentation, I came up with the following, which seems to do what
I want:

-- start build.gradle --

version = "0.1"

configurations {
 deploy
}

dependencies {
 deploy 'org.codehaus.groovy:groovy-all:2.5.4'
}

repositories {
 jcenter()
}

task copyDeps(type:Copy, group: "Custom", description: "Copies project
dependencies") {
 from configurations.deploy.collect { it.absolutePath }
 into "dest/lib"
}

task copy(type: Copy, group: "Custom", description: "Copies sources to
the dest directory") {
 from "src"
 include "*.groovy"
 into "dest"
}

task deploy(type:Zip, group: "Custom", description: "Build a deployment zip") {
 dependsOn copyDeps
 dependsOn copy
 from "dest"
 setArchiveName "${project.name}-${project.version}.zip"
}

-- end build.gradle --

It doesn't create a fat jar yet, but I can look into setting that up.
The various existing plugins seem to be dependent upon the
infrastructure set up by the java plugin, which I don't really
understand (or need, as far as I can tell) so they may not be of much
help. But I'm not sure what I need to do yet to write my own.
Something simple like

task customFatJar(type: Jar) {
 dependsOn copyDeps
 baseName = 'all-in-one-jar'
 from "dest/lib"
}

gives me an "all-in-one-jar.jar" that contains the dependency jars
directly included, rather than being unpacked. So there's more I need
to do here...

Paul





Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread Paul Moore
On Wed, 19 Dec 2018 at 22:33, Paul Moore  wrote:

> Something simple like
>
> task customFatJar(type: Jar) {
> dependsOn copyDeps
> baseName = 'all-in-one-jar'
> from "dest/lib"
> }
>
> gives me an "all-in-one-jar.jar" that contains the dependency jars
> directly included, rather than being unpacked. So there's more I need
> to do here...

Actually, I found the following on the web, which seems to work:

task customFatJar(type: Jar) {
dependsOn copyDeps
baseName = 'all-in-one-jar'
from {
configurations.deploy.collect {
it.isDirectory() ? it : zipTree(it)
}
}
}

I'm not at all sure *why* it works, but it does :-)

Paul


Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread Paul Moore
On Wed, 19 Dec 2018 at 21:23, James Kleeh  wrote:
>
> Paul,
>
> The best solution is to use Maven or Gradle to create an all-in-one (fat) jar 
> that you can ship and run with java -jar
>
> Gradle has a shadow plugin and Maven has a shade plugin to do just that.

Thanks. I'd come to the conclusion that Gradle was likely the solution
I should be looking at, and I've spent the evening trying to set up a
basic Gradle script that does what I want. After a lot of
experimentation, I came up with the following, which seems to do what
I want:

-- start build.gradle --

version = "0.1"

configurations {
deploy
}

dependencies {
deploy 'org.codehaus.groovy:groovy-all:2.5.4'
}

repositories {
jcenter()
}

task copyDeps(type:Copy, group: "Custom", description: "Copies project
dependencies") {
from configurations.deploy.collect { it.absolutePath }
into "dest/lib"
}

task copy(type: Copy, group: "Custom", description: "Copies sources to
the dest directory") {
from "src"
include "*.groovy"
into "dest"
}

task deploy(type:Zip, group: "Custom", description: "Build a deployment zip") {
dependsOn copyDeps
dependsOn copy
from "dest"
setArchiveName "${project.name}-${project.version}.zip"
}

-- end build.gradle --

It doesn't create a fat jar yet, but I can look into setting that up.
The various existing plugins seem to be dependent upon the
infrastructure set up by the java plugin, which I don't really
understand (or need, as far as I can tell) so they may not be of much
help. But I'm not sure what I need to do yet to write my own.
Something simple like

task customFatJar(type: Jar) {
dependsOn copyDeps
baseName = 'all-in-one-jar'
from "dest/lib"
}

gives me an "all-in-one-jar.jar" that contains the dependency jars
directly included, rather than being unpacked. So there's more I need
to do here...

Paul


Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread Nelson, Erick
Grab caches it files by default in your user home directory in .groovy/grapes

Just zip up that dir and copy it to the server you want it on, and extract it. 

Sent from my iPhone

> On Dec 19, 2018, at 1:24 PM, James Kleeh  wrote:
> 
> Paul,
> 
> The best solution is to use Maven or Gradle to create an all-in-one (fat) jar 
> that you can ship and run with java -jar
> 
> Gradle has a shadow plugin and Maven has a shade plugin to do just that.
> 
> James
> 
>> On Dec 19, 2018, at 4:19 PM, Paul Moore  wrote:
>> 
>> On Wed, 19 Dec 2018 at 20:18, Søren Berg Glasius  wrote:
>>> 
>>> 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.
>> 
>> Thanks - yes, I've seen @Grab, and used it while testing. But the
>> problem is that it puts the dependency files "somewhere", but not
>> alongside the script. I need to ship the script and its dependencies
>> to another machine with no web access, so I need better control over
>> where the dependencies end up. (I could probably hunt out where the
>> files downloaded by @Grab went, but it would be a completely manual
>> task to locate them all and copy them, and mistakes would happen - so
>> I'd prefer something automated.
>> 
>> Paul
> 


Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread James Kleeh
Paul,

The best solution is to use Maven or Gradle to create an all-in-one (fat) jar 
that you can ship and run with java -jar

Gradle has a shadow plugin and Maven has a shade plugin to do just that.

James

> On Dec 19, 2018, at 4:19 PM, Paul Moore  wrote:
> 
> On Wed, 19 Dec 2018 at 20:18, Søren Berg Glasius  wrote:
>> 
>> 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.
> 
> Thanks - yes, I've seen @Grab, and used it while testing. But the
> problem is that it puts the dependency files "somewhere", but not
> alongside the script. I need to ship the script and its dependencies
> to another machine with no web access, so I need better control over
> where the dependencies end up. (I could probably hunt out where the
> files downloaded by @Grab went, but it would be a completely manual
> task to locate them all and copy them, and mistakes would happen - so
> I'd prefer something automated.
> 
> Paul



Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread Paul Moore
On Wed, 19 Dec 2018 at 20:18, Søren Berg Glasius  wrote:
>
> 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.

Thanks - yes, I've seen @Grab, and used it while testing. But the
problem is that it puts the dependency files "somewhere", but not
alongside the script. I need to ship the script and its dependencies
to another machine with no web access, so I need better control over
where the dependencies end up. (I could probably hunt out where the
files downloaded by @Grab went, but it would be a completely manual
task to locate them all and copy them, and mistakes would happen - so
I'd prefer something automated.

Paul


Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread Søren Berg Glasius
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  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
> 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
>


Re: What is the best replacement for running scripts using groovy-all?

2018-12-19 Thread Paul Moore
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 
> > 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


Re: What is the best replacement for running scripts using groovy-all?

2018-12-18 Thread Keith Suderman
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 


- Keith


> On Dec 17, 2018, at 3:49 AM, Paul Moore  > 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