does lein2 use repositories defined in ~/.m2/settings.xml?

[James Xu]

I have a lein project, if using lein2(lein2 deps), it gives me the following errors:

james:alitoolkit(git:master)$ lein deps

Could not find metadata com.alibaba.platform.shared:dubbo.rpc/maven-metadata.xml in local (/home/james/.m2/repository)

Could not find metadata com.alibaba.platform.shared:dubbo.remoting/maven-metadata.xml in local (/home/james/.m2/repository)

Could not find metadata com.alibaba.platform.shared:dubbo/maven-metadata.xml in local (/home/james/.m2/repository)

Could not find metadata com.alibaba.platform.shared:dubbo.core.api/maven-metadata.xml in local (/home/james/.m2/repository)

Could not find metadata com.alibaba.platform.shared:dubbo.core.common/maven-metadata.xml in local (/home/james/.m2/repository)

Could not find metadata com.alibaba.platform.shared:dubbo.core.registry.default/maven-metadata.xml in local (/home/james/.m2/repository)

Could not find metadata com.alibaba.platform.shared:dubbo.core.rpc/maven-metadata.xml in local (/home/james/.m2/repository)

Could not find metadata com.alibaba.platform.shared:dubbo.core.rpc.dbo/maven-metadata.xml in local (/home/james/.m2/repository)

Could not find metadata com.alibaba.platform.shared:dubbo.core.rpc.http/maven-metadata.xml in local (/home/james/.m2/repository)

Could not find metadata com.alibaba.platform.shared:dubbo.core.service/maven-metadata.xml in local (/home/james/.m2/repository)

Could not find metadata com.alibaba.platform.shared:dubbo.core.service.server/maven-metadata.xml in local (/home/james/.m2/repository)

Could not find metadata com.alibaba.platform.shared:dubbo.registry.client/maven-metadata.xml in local (/home/james/.m2/repository)

This could be due to a typo in :dependencies or network issues.

Could not resolve dependencies

but If I use lein1, it can resolve all the dependencies successfuly, com.alibaba.platform.shared:dubbo.* can only be found in the repositories specified in ~/.m2/settings.xml, so it seems that lein2 does not use ~/.m2/settings.xml?

[Michael Klishin]

2013/2/21 James Xu <xumingmin...@gmail.com>

so it seems that lein2 does not use ~/.m2/settings.xml

Correct. Specify them in project.clj.
--
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

[James Xu]

Thanks! But it sounds odd to me that lein does not use ~/.m2/settings.xml, why this decision?

--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Michael Klishin]

2013/2/21 James Xu <xumingmin...@gmail.com>

Thanks! But it sounds odd to me that lein does not use ~/.m2/settings.xml, why this decision?

I wasn't the one who's made this decision but here's my understanding.

Leiningen 2 uses Aether for dependency management. Aether doesn't use ~/.m2/settings.xml

by default.

In addition, many Clojure newcomers don't know what ~/.m2/settings.xml is and are scared away

by anything with ".xml" in it. They want to write Clojure, not XML.

[James Xu]

Thanks again for the explanation :)  That make sense, just not so easy for newcomers from java world like me to figure it out at first glance.

From: Michael Klishin <michael....@gmail.com>
Reply-To: <clo...@googlegroups.com>
Date: Thu, 21 Feb 2013 13:28:48 +0400
To: <clo...@googlegroups.com>
Subject: Re: does lein2 use repositories defined in ~/.m2/settings.xml?

[Chas Emerick]

On Feb 21, 2013, at 4:28 AM, Michael Klishin wrote:

2013/2/21 James Xu <xumingmin...@gmail.com>

Thanks! But it sounds odd to me that lein does not use ~/.m2/settings.xml, why this decision?

I wasn't the one who's made this decision but here's my understanding.

Leiningen 2 uses Aether for dependency management. Aether doesn't use ~/.m2/settings.xml

by default.

Aether actually has no facilities for consuming settings.xml AFAIK — that's entirely part of the mvn toolchain, not the underlying libraries.

- Chas

[David Powell]

Just wondering; if you want to specify an internal nexus repo in one place, can you specify it in ~/.lein/profiles.clj ?

-- 

Dave

--

[James Xu]

Yeah,  just don't know I need to do this before.

From: David Powell <djpo...@djpowell.net>
Reply-To: <clo...@googlegroups.com>
Date: Thu, 21 Feb 2013 10:06:15 +0000
To: <clo...@googlegroups.com>
Subject: Re: does lein2 use repositories defined in ~/.m2/settings.xml?

[Phil Hagelberg]

James Xu writes:

> Thanks! But it sounds odd to me that lein does not use ~/.m2/settings.xml,
> why this decision?

Leiningen never explicitly supported settings.xml; it was checked by
accident as an implementation detail due to lein1 using maven-ant-tasks
rather than Aether. But the better answer is that Leiningen isn't Maven,
and supporting some subset of settings.xml without supporting all of it
is confusing.

> Just wondering; if you want to specify an internal nexus repo in one place,
> can you specify it in ~/.lein/profiles.clj ?

It's possible, but highly discouraged. If your project requires certain
repositories in order to operate, you should declare them in project.clj.

Specifying authentication for private repos in the user profile, on the
other hand, is highly recommended.

-Phil

[David Powell]

> Just wondering; if you want to specify an internal nexus repo in one place,
> can you specify it in ~/.lein/profiles.clj ?

It's possible, but highly discouraged. If your project requires certain
repositories in order to operate, you should declare them in project.clj.

Specifying authentication for private repos in the user profile, on the
other hand, is highly recommended.

-Phil

I can see it being an anti-pattern for open-source projects hosted on the internet, but the scenario that I am experimenting with is a single nexus server within an organisation, used to mirror clojars & central, as well as act as a repository for internal closed-source components.

Putting repos in profiles.clj seems to have the advantage that I'll be able to override all accesses to central / clojars / etc to go via the nexus proxy; and I won't have to start hacking at published project.cljs if infrastructure changes mean that the repo server moves or fragments or whatever.

Does that sound reasonable?  (I'm a noob at maven infrastructure).

-- 

Dave

[Chris Jeris]

On Thu, Feb 21, 2013 at 12:44 PM, Phil Hagelberg <ph...@hagelb.org> wrote:

It's possible, but highly discouraged. If your project requires certain
repositories in order to operate, you should declare them in project.clj.

Just as a data point, we're currently using a profiles.clj on each of our build agents to declare our internal Nexus repos (including our mirrors of Maven Central and Clojars), because that is more maintainable for us than repeating the entire repo declaration in every one of our project.clj files.  For Maven projects, we can use a parent pom, but there isn't any corresponding "parent project" concept for Leiningen, correct?

I experimented a bit with trying to use a Lein middleware to supply the repo entries, but unless you install the middleware manually, that ends up begging the question, since Lein has to know where to get the middleware.

--
Chris Jeris
cje...@brightcove.com
freenode/twitter/github: ystael

[Phil Hagelberg]

David Powell writes:

> Putting repos in profiles.clj seems to have the advantage that I'll be able
> to override all accesses to central / clojars / etc to go via the nexus
> proxy; and I won't have to start hacking at published project.cljs if
> infrastructure changes mean that the repo server moves or fragments or
> whatever.

Sure; introducing mirrors is different from introducing entirely new
repositories. Mirrors simply streamline and speed things up rather than
providing entirely new artifacts, so they don't really change the
semantics of what you end up with.

-Phil