Can't speak for Per, but for us, it would be patently absurd to embed all the libraries into our executable. It's partially the storage, for we have a number of applications which share the libs, but much more important would be the upload time when we changed our code (which happens pretty often).
Just lately I've hunted for an ugly bug which, alas, did happen on the server only, not at my side. I've rebuilt and uploaded each ten-odd minutes. Should I have to upload a monster JAR containing all the libs, I'd be doing that still the very now. All the best, OC > On 24. 2. 2025, at 1:51, steve.etchel...@gmail.com wrote: > > 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 > <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 <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 >> <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 >>> <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 > >
