Re: What is the best replacement for running scripts using groovy-all?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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 ;-)) Paul