Maven also downloads jars and dependencies automatically as a typical part
of its functionality. It typically saves them in
"${user.home}/.m2/repository/<group-name>/<artifact-name>/<version>/<artifact-name>-<version>.jar"
The naming is pretty consistent because maven strongly encourages everyone
to use the same conventions. (javadoc would be in the same directory as
<artifact-name>-javadoc.jar and source code is often placed there as
<artifact-name>-sources.jar). All of this should be picked up from the
"pom" (project object model) xml file, but most projects follow those
conventions. <group-name> is arbitrary but often follows something similar
to the java package <domain.name> convention.
All of that seems to pretty much describe what you'd want from a packaging
system really. The only problem is that maven users sometimes have a
tendency to demand everyone package stuff up in the format that would be
convenient to them (though maven supports packaging 3rd-party libraries,
some people prefer that the upstream does the packaging, and sometimes
upstream doesn't actually want to be bothered with it).
You can browse around on http://repo1.maven.org/maven2/ to get more of an
idea how it looks in practice.
Hypothetical clojure sytax might look like:
(depends-on :group "antlr" :artifact "antlr" :version "2.7.1")
or
(depends-on :group "antlr" :artifact "antlr" :version "2.7.1" :repository "
repository.example.com")
Another alternative might be if the packaging system inter-operated with
java web start. .jnlp files also provide much of the same version and
authoritative source information.
-- Aaron
On Sun, Mar 22, 2009 at 10: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.
>
> -Phil
> http://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
-~----------~----~----~----~------~----~------~--~---
