On Thu, Aug 6, 2009 at 4:12 PM, Lauri Pesonen<lauri.peso...@iki.fi> wrote: > 2009/8/5 Meikel Brandmeyer <m...@kotka.de>: >> Well, this is independent of whether you have a C or Java >> library. You can install each C library in its own directory >> and tell the linker to look there. Then you have basically >> a .jar like setup: If you don't tell the linker the right directory >> the library "is not there". Similar you can declare "/usr/java/lib" >> as your global directory and unzip each and every jar there. >> Then configure your java launcher to add that directory to >> the classpath and you have a setup, like the usual one >> for C libraries. So this could even be system policy. > > What I was trying to say is that in the native lib world there are > standard locations that the linker has been configured to look at and > as a result the user does not have to do anything. That's not the case > in the Java world, where the user has to always set the classpath to > point to libs that the app uses. > > My point is that life is easier for languages that use native > libraries as extensions rather than Java, because things just work. > Placing all my jar files in /usr/java/lib only solves the problem for > me if I tell the JVM to look there, plus the JVM will not resolve jars > unless I name each jar separately on the classpath, and finally > putting all my jars in one directory will not help the users of my > package since it's not a universal convention. > > In the Ruby world, Gems expect their native dependencies to be > installed on the platform at Gem install time. The Gem install will > fail if the native library is missing. It is up to the user to install > the dependency before trying to install the Gem. The user is free to > install the dependency in which ever manner he chooses: a source > install, a binary install, install via another package manager (e.g. > apt-get or MacPorts) etc.
Yes, but the global approach is extremly unflexible. While I can see that you probably never want to have two different versions of yor X11 libraries on the system, if you happen to want them, it's probably going to be a major hassle to manage (unless you use a VM for it). Scenario: You have an application as v1.0 in production and it uses a library X in v2.1 (or whatever). Now you're developing developing the next version of your application (v2.0) and you're upgrading library X (to v3.0) in your system since you want the new functionality. The new X v3.0 is not backwards compatible. You find a critical bug in the production version v1.0 while you're happily developing for v2.0 of your app. With your version control system, checking out a parallel install for the production version (v1.0) is easy. With the proposed package manager / dependency system, can you have both versions of said application on your system and launch them without reconfiguration? If you have the classpath setup as a project local dependency file, then you can do this (this is what maven/ivy/virtualenv(python)/zc.buildout(python)/etc. gives you). If you have a global static dependency resolution (path or whatever), then it's going to be diffcult. Whatever approach is chosen (rewrite/wrap/use existing), IMHO this scenario has to be supported by the final system. >> All these setups can be done (more or less comfortable) >> with today existing solutions for Java. Instead of re-inventing >> those, it would be more useful to abstract away their specifics. >> Create a meta-package manager which creates JVM, CLR >> and whatever packages sitting on the existing infrastructure >> for the respective platform. Have a look at Buckminster: http://www.eclipse.org/buckminster/ Not sure if it's going to work for non-JVM approaches (you'll probably have to code up a plugin of some sort), but it's a meta package manager, and can do more than just dependency resolution. For instance, you can specify, if you would like to have a dependency as a published Jar, or if you would like it to be checked from the version control system, so that you can fix bugs in the dependency. Note that this is the most under-documented project I have found in a long time. It's powerful, but unless you use the Eclipse IDE, it's not easy to have it do your bidding. So it might or might not be of interest for our problem. I personally think that the JVM ecosystem became more important because of the dependency configuration approach, since although it's painful to manage if you don't have tools, it's powerful for mixing and matching dependencies in multiple projects on the same machine. This gives you the possibility to try out without jeopardizing your existing project configurations. Just my two cents, Daniel --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
