> How about having a Clojure application 'package' set up a launcher > script to launch the app with a minimal classpath, Leiningen style, > based on some assumption regarding the whereabouts of versioned jars > on the system? (E.g. jline-0.9.94.jar rather than jline.jar, say.)
Something along those lines was what I had in mind (rather than, as you say, just drop everything onto the CLASSPATH). It would not be something you want to fuss with necessarily during development, but some standard way of "building" your application in a packaging friendly manner. > Note that it will never do to have dependencies handled by a system > which isn't capable of installing several versions of the same jar > side-by-side... I don't know what apt / rpm / ports do about Java lib > versioning, so maybe there's no problem here? As far as I can tell, few Java things are packaged. I suspect because of this reason, in part. Things that are packaged tend to be those things that depend only on the JDK itself, or on very simple dependencies, or else major stuff like 'eclipse' which release engineering and huge dependency trees are not your concern. But as far as I have encountered, there is no magic solution to the multiple-versions-of-the-same-library problem that integrate with native OS packaging systems (that doesn't mean there are none). Maybe for Clojure it would indeed be more desirable to have some well-defined interface for packaging systems to use when dealing with clojure applications. It may not be entirely trivial though. For example with FreeBSD ports, the build step is expected to only depend on downloading certain well-defined and checksum controlled files from remote locations. You do not want something that arbitrarily downloads stuff during building. I'm pretty sure similar conventions exist for e.g. Debian. It's a difficult problem, and I'm not blaming Clojure. Especially since I think the Java/Clojure/Maven way of dealing with dependencies is vastly superior to the traditional way. 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? Actually, how is this dealt with in the Maven community? -- / Peter Schuller -- 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
