The reasons are: 1. Storage: I can easily package an analysis into a simple runnable format that takes up negligible space (<1 mb). To put all groovy jars in side the jar increases the size by 25+ MB which over time becomes significant 2. From the philosophical standpoint of Groovy as a first-class citizen instead of as a “java enhancement” I think specifying the groovy version to use to get identical outcome is on the same level (almost) as specifying which java version to use 3. The groovy version can be distributed to all users as part of the set of applications that are standard in the company. If something breaks, then there is a task of creating specific fix for that package but if groovy libs were bundled in the jar, then ALL such applications would need to be replaced whenever a new Groovy version becomes the standard which is MUCH more involved.
Regards, Per From: "steve.etchel...@gmail.com" <steve.etchel...@gmail.com> Reply to: "users@groovy.apache.org" <users@groovy.apache.org> Date: Monday, 24 February 2025 at 01:52 To: "users@groovy.apache.org" <users@groovy.apache.org> Subject: RE: Groovy -jar You don't often get email from steve.etchel...@gmail.com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> Per, Out of curiosity why wouldn’t you want to include groovy jars in every jar bundle. Is it the maintenance of groovy security patches? It isn’t the storage is it? From: o...@ocs.cz <o...@ocs.cz> Sent: Sunday, February 23, 2025 11:27 AM To: users@groovy.apache.org Subject: Re: Groovy -jar Per, we sort of have debated this some time ago, when groovy-all.jar was, sadly, removed. We use a similar approach, nevertheless, we need much more complex classpath. On the other hand, since we deploy WebObjects, we just could take the standard NeXT/Apple WO launch script and very slightly change the thing. Almost surely won't be useable for anybody as-is (too much of the old, not-needed-today stuff), but just for comparation/ideas, should you want to, you may check it at https://ocs.cz/CD/ServerLaunchScript, and one of our classpaths (our build scripts generate them build-time along with JAR creation) at https://ocs.cz/CD/ClassPath.txt. All the best, OC On 23. 2. 2025, at 12:40, Per Nyfelt <p...@alipsa.se<mailto:p...@alipsa.se>> wrote: Thanks for this! For the use case you mention it makes perfect sense to do it that way. Since I don't want to include groovy jars in every jar bundle, I ended up with this instead: https://github.com/Alipsa/groovyjar/blob/main/groovyjar I still think something similar would be nice and useful as part of the groovy distribution (e.g. when installed by sdkman) Best regards, Per On 2/23/25 01:53, steve.etchel...@gmail.com<mailto:steve.etchel...@gmail.com> wrote: Hi Per, I have had (very) good luck with a slightly different approach. Rather than ‘groovy -jar myapp.jar’ I went with ‘java -jar myapp.jar’. And this had another, somewhat unexpected, benefit. Building my app with shadowJar<https://gradleup.com/shadow/> (thanks to the help I received here) it bundled all of groovy, all my library dependencies (database drivers, etc), and my app into my jar file. As a result, I don’t even need to install groovy on a target machine – just copy the one jar file (myapp.jar) to the target machine and run it via ‘java -jar myapp.jar’ and everything completely works. Of course this assumes that Java has been installed but that’s pretty ubiquitous these days and a requirement anyway. And I don’t have to worry about the version of groovy that happens to be installed on that machine as the execution will use the version of groovy that is inside my jar file. You can review a working example of this at https://github.com/mre-code/groovysql. Now unfortunately, due to Java’s newer encapsulation direction<https://dev.java/learn/modules/strong-encapsulation/> (which does make a lot of sense) I ended up needing to provide a shell wrapper to provide all of the –add-opens settings required for (older) Java database drivers (which I use for this app). Now if it weren’t for those older Java database drivers which are using reflection I would not need the little shell wrapper and could just use ‘java -jar groovysql.jar’ (or even the binfmt approach discussed in the groovysql repository where you can just make the jar file executable and run it as ‘groovysql’ after removing the .jar extension from the file). For background, the little shell wrapper is located in src/main/bin/groovysql in that repository. So in order to run my app, all that anyone needs to do is to copy my jar file and the little shell wrapper from the Releases and place them somewhere in their PATH and it’s ready to run. No groovy install, no database driver installs, no configuration, just go. Hope this helps, Steve From: Per Nyfelt <p...@alipsa.se><mailto:p...@alipsa.se> Sent: Saturday, February 22, 2025 2:34 PM To: users@groovy.apache.org<mailto:users@groovy.apache.org> Subject: Groovy -jar Hi, I find myself missing a way to execute groovy jars e.g: `groovy -jar someapp.jar`. As a workaround i can do something like the following in bash (error handling etc. omitted) #!/usr/bin/env bash # takes a single parameter (the path to the jar file to execute - it assumes the Main-Class attribute has been set) jarName="$1" mainClass=$(unzip -p "$jarName" "META-INF/MANIFEST.MF" | grep 'Main-Class:' | awk '{ print $2 }' | tr -d '\r') java -cp $jarName:$GROOVY_HOME/lib/* $mainClass But it would be nice to support this "natively" in groovy with `groovy -jar` Has support for this been discussed before? Best regards, Per
