James Williams
LinkedInMastodonGithub

Groovy package ideas

Tags: Groovy

So I've been poking around a bit learning Debian policy and how to build from source, which, by the way is much more difficult that building a regular binary package but anyways... Usually in Debian-land, applications live in usr/share and libraries live in usr/lib.

When you want to add, for example groovy-xmlrpc, you generally either add the jar or a link to the jar in the GROOVY_HOME/lib directory. This becomes a little bit problematic when you upgrade versions. Putting the jars directly in lib/ makes it where the groovy package would have to enumerate every core lib and preserve jars not on the list. Not really fun and prone to errors if a dependency changes, etc, etc. On the other hand, installing libraries in /usr/lib/xxx seems like a bit much for a one-off jar. But they do need to go somewhere.

In one of my random chats with Andres, I kinda tossed around the idea of adding a GROOVY_HOME/extra-libs directory and a small bash script(in GROOVY_HOME/bin) to recurse the list in extra-libs and create symbolic links after an upgrade to handle optional libraries more gracefully.

I was thinking something like this: GROOVY_HOME/extra-libs/ GROOVY_HOME/extra-libs/swingxbuilder GROOVY_HOME/extra-libs/swingxbuilder/0.1.5 GROOVY_HOME/extra-libs/swingxbuilder/0.1.5/swingxbuilder.jar

Under such a scheme, you could have everything in one place and organized with access to multiple versions of a library. It would symlink the latest version but the user can arbritrarily add an older version to the classpath of an application if needed . AFAIK Windows has limited symlink capabilities, so this would be a UNIX/BSD only thing. But as a packager, it makes my job a whole lot easier.

What do y'all think?