On Feb 6, 1:06 pm, Peter Schuller <peter.schul...@infidyne.com> wrote: > But the practical issue > remains that if I want to write some software that I want sysadmins in > various situations to want to use effortlessly (in my case, a backup > tool), problems like these do get in the way of choosing Clojure. > > Maybe uberjars are the pragmatic approach after all. But then what > about GPL libraries and similar license hassles?
I can't comment on the licensing problem, but could you expand on what exactly you don't like about packaging jars (as uberjars or separates) and distributing them as part of your application? If you distribute your app with precisely the jars you tested with, you don't have to worry about subtle incompatibilities sneaking in. Except for obviously bloated software (e.g., JBoss), Java jar files are relatively small. When you package for Debian, put the jars in /usr/share/my-awesome-app/ jars, put in a dependency on sun-java-1.x, and provide a wrapper shell script to start the whole thing (your classpath just includes the stuff you provided). For the installing admin, your package is just an "aptitude install my-awesome-app" away, and it just pulls down a JVM dependency. Simple, and fairly lightweight. I stopped using Python and Ruby and Perl partly because the packaging situation for all those languages is a horrible mess. For example, if you write a Ruby app, you are highly likely to run into trouble packaging it even for a recent distribution because your dependencies may not have been packaged or made available as rb-*.debs in the official repository. Or, rb-*.debs exist, but provide an incompatible version of the library you need. Ubuntu and Fedora may ship different versions of common gems, so you can't even code against an obvious lowest common denominator. (To make matters worse, "gem install", "easy_install", and "cpan -i" all create weird parallel universes of packages which may cause conflicts with system-provided packages. Python's virtualenv helps mitigate the problem to some extent.) C programs have it easier, because the overwhelming majority of commonly used libraries are packaged and available in recent distributions, and I have rarely had trouble with just writing against a slightly older version of a library. It's perfectly reasonable to dynamically link against libjpeg and make a note of a libjpeg dependency in the package descriptor file. In short, I think that the Java and Clojure way of packaging software make life much easier for programmers, package maintainers, and administrators, not harder. Making applications self-contained helps avoid dependency hell at packaging and deployment time, not to mention during development. It's a bit wasteful to have multiple copies of log4j or whatever floating around, but I'd rather waste a few gigabytes of disk space on duplicates than deal with system-wide classpaths. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
