Answer to lein's checkout dependencies

92 views
Skip to first unread message

Chas Emerick

unread,
Nov 8, 2010, 10:57:39 AM11/8/10
to clojure-ma...@googlegroups.com
I don't know if there's interest in this, but there might be some mileage to be gained out of providing a corollary to leiningen's "checkout dependencies", described here:

https://github.com/technomancy/leiningen

The gist of it is that, absent an IDE with good maven support (i.e. when using clojure:run, :repl, :swank, etc), related projects cannot be referred to in any way other than via installed dependency artifacts (AFAIK, anyway). This seems just a little evil to me (distinctly intermingling concerns IMO), but insofar as people don't have a maven-capable IDE that enables the use of sources, etc., without an install cycle, something like this is desirable.

FWIW, Chris Houser and others have brought up this issue as a potential blocker for those that might otherwise use maven and clojure-maven-plugin (and perhaps therefore, hopefully, leading to fewer build and CI headaches for those of us that worry about such things):

http://groups.google.com/group/clojure-dev/msg/bcc84c6b9975d145

I was thinking that perhaps instead of some listing of source paths, a pompath property (to coin a [bad?] term) might be more useful: just like a classpath, but each element pointing at other projects' pom files (OK, maybe also allowing for directories assumed to be source dirs), which clojure:repl et al. would load up through the POM APIs read to find additional source- and classpaths to add to the new process' classpath.

Does this sound sane? Is there already a way to add arbitrary entries to a maven project's classpath in order to influence clojure:repl et al.? (no points for suggesting system-scoped dependencies :-)

Cheers,

- Chas

Chouser

unread,
Nov 9, 2010, 9:19:08 AM11/9/10
to Clojure Maven Plugin
On Nov 8, 10:57 am, Chas Emerick <cemer...@snowtide.com> wrote:
>
> I was thinking that perhaps instead of some listing of source paths,
> a pompath property (to coin a [bad?] term) might be more useful:
> just like a classpath, but each element pointing at other projects'
> pom files (OK, maybe also allowing for directories assumed to be
> source dirs), which clojure:repl et al. would load up through the
> POM APIs read to find additional source- and classpaths to add to
> the new process' classpath.

That sounds like what I want, though perhaps I see your point about
the evilness of developers putting local paths to other pom files in
a project's pom.xml.

I guess IDEs generate another file entirely for that --
a developer-local project file of some sort? I'd be fine with that
too as long as there was some way for some external tool to pass in
a generated classpath to clojure:repl and friends.

--Chouser
http://joyofclojure.com/

Hugo Duncan

unread,
Nov 9, 2010, 11:21:55 PM11/9/10
to Clojure Maven Plugin
A solution to this would definitely be of interest to me:)

Hugo

Mark Derricutt

unread,
Nov 14, 2010, 5:13:37 PM11/14/10
to clojure-ma...@googlegroups.com
I came across this plugin this morning:

http://evgeny-goldin.com/wiki/Maven-find-plugin

which looks like it could be useful in this scenario, ish.  At least it could be a basis for ongoing ideas.

I was thinking you don't really want to hard code any source directories in the pom, but some way of resolving them, possibly based on the GAV, or some other identifier.

Mmmm


--
"Great artists are extremely selfish and arrogant things" — Steven Wilson, Porcupine Tree
Reply all
Reply to author
Forward
0 new messages