Hello Per, If I understand your problem correctly I have a solution for you. It will however not work for cloud deployment!!
In a project a long time ago we setup what we called **-platform. This was a JEE app. The ** was the company name. In that folder we put a subforlder for deployments. We also added a jar folder containing most of the jars we needed. Then we made a script to start/stop/restart the "platform". It also contained a set of configuration files in a config subfolder. This platform was an updatable package. This also made it easy to ensure everyone had the same setup since we also had local installation for developers. Anyhow this separated most of the code from from dependency details. But as I said abvove if you are running in a cloud platform this will not work as fae asa I know. Regards, Tommy ______________________ Tommy Svensson to...@natusoft.se On 24 Feb 2025 at 18:39 +0100, Per Nyfelt <per.nyf...@nordnet.se>, wrote: > 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 > 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> 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 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 (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 (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> > > > Sent: Saturday, February 22, 2025 2:34 PM > > > To: 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 >
