Groovy package ideas

06 January, 2008    
Written by

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?

Comments

  1. Glen Smith said:

    I copy mine to ~/.groovy/lib to insulate myself from groovy version upgrades. Seems to work fine (but it is user-specific, which might not work for you).
  2. Dierk Koenig said:

    cool. I like the idea. It goes into the direction of what perl/ruby/python distros do, i.e. core distro plus local additions in a subdir. How about 'modules' instead of 'extra-libs'? cheers Dierk
  3. Danno Ferrin said:

    I am workign on somthing similar in the proposals section: http://docs.codehaus.org/display/GROOVY/Grapes+and+grab%28%29
blog comments powered by Disqus