2009/3/23 Warren <warrenthomasw...@yahoo.com> > > Sounds like OSGi. Any progress on Clojure working with OSGi?
Hello, For the general OSGi infrastructure, I don't know. For Eclipse in particular, yes: I've succesfully run a "proof of concept" class from within clojuredev. To be able to do that, I have used the Eclipse "buddy" feature, more specifically the "registered" policy which allows a plugin (here the plugin with clojure core) to search classes in the plugins that depend on itself AND also registered themselves specifically as "buddies" of the "clojure" plugin. Though, I think it is an eclipse extension to the OSGi platform. There was also a success case reported by Gaetan, but this currently requires (as far as I know) to patch clojure, and since I haven't seen the code yet, I can't tell if there's a chance, by modifying it, to make it an acceptable patch for clojure core. -- Laurent > > > On Mar 22, 9:59 pm, Phil Hagelberg <p...@hagelb.org> wrote: > > Bradbev <brad.beveri...@gmail.com> writes: > > > I feel that the next big growth phase for Clojure will be in the user > > > community and the code that we can generate. A good package manager > > > will help fuel that growth. > > > > I agree. The more I work with packages that have dependencies the more I > > realize that manually managing them will simply not scale. > > > > > And now I'll cop out & say that I have no idea about how to actually > > > implement this sort of thing - I'm hoping somebody else will want to > > > do it for me :) > > > > As Paul mentioned, adding to the classpath at runtime supposedly is > > fraught with peril, though I've never got a clear answer whether this > > applies to Clojure code or just Java code. I suspect it may be workable > > to have shell scripts that set up the classpath rather than calculating > > it from within Clojure code. This may be the trickiest part of the > > implementation since most languages with package managers have a load > > path mechanism that's much more flexible than the JVM's. > > > > I definitely think being able to read from the Maven repository format > > sounds like a good idea, though I haven't had too much interaction with > > the tool itself. > > > > It would probably be good to just start brainstorming about what > > features would be needed for such a tool: > > > > * Servers need to host jars as well as indices of metadata about jars > > that would indicate versions, descriptions, and dependencies between > > jars. > > > > * The client needs to be able to download jars and their dependent jars > > and store them on disk. Multiple versions of a library should be able > > to be installed at once. (apt-get doesn't support this natively, and a > > lot of unfortunate hacks are needed to work around this.) Packages > > should be able to specify which servers each dependency should come > > from. Jars should be able to be installed on a system-wide level as > > well as in a user's home directory. > > > > * Code needs to be able to state its dependencies, probably as part of > > the ns macro. Flexible version declarations will be necessary. (eg. I > > need exactly version 1.8.0 of a library, I need at least version 2.3.1 > > of a library, or I need any version in the 0.9 series starting with > > 0.9.1 but allowing in bugfix point-releases.) > > > > Anything else? I'd love to help out with implementation, whether by > > hacking Sauron or some other (hopefully less evil) alternative, but I > > think it's important that our efforts be unified. > > > > -Philhttp://technomancy.us > > > > --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
