Transitive dependency resolution from custom repositories fails

[GoogleCodeExporter]

Dependency resolution from repositories specified in project.clj has been fixed 
for issue #653. But it does not work transitively when another project depends 
on a project that uses dependencies from a custom repository.

Setup:
1. Project A with dependencies from a custom repository, e.g. the pallet 
example from #653.
2. Project B that uses Project A as dependency. Project B does not specify any 
custom repository.

In Leiningen this works as intended. In CCW 0.30.0 the dependencies (e.g. 
pallet) used for Project A can not be found for Project B.

Original issue reported on code.google.com by Gunnar.V...@googlemail.com on 27 Nov 2014 at 12:34

[GoogleCodeExporter]

I'm not sure I totally understand the issue yet.

- is this a regression in CCW 0.30.0 ?

- Is the problem in the `Leiningen classpath dependencies` node in the 
project's package folder (and then if you use CCW to create the classpath when 
running a REPL, instead of leiningen which is the default) ? Or does it 
also/instead occur when Leiningen is used by the launcher ?

There may be problems since I switched from Leiningen 2.3.4 to Leiningen 2.5.0.

CCW still relies on some Leiningen APIs, but this was never really stable 
enough to my taste.

I intent in the future to totally remove leiningen from ccw's classpath, and 
instead always call leiningen by launching it via java processes. This will 
slow down some features (e.g. update of dependencies when project.clj changes), 
but at least we will cut down the number of regressions to near 0 when 
leiningen changes versions (and for the remaining regressions, hopefully 
simplify their resolution).

Original comment by laurent....@gmail.com on 27 Nov 2014 at 4:04

• Changed state: InfoNeeded

[GoogleCodeExporter]

I start the REPL using leiningen. So the problem does only affect "Leiningen 
classpath dependencies" and produces an error similar to issue #653.
The difference is that in issue #653 a dependency from a custom repository was 
directly specified in the project.clj of project A.

Now, I have a second project B that depends on project A. I guess the solution 
to fix issue #653 does not use custom repositories specified in the 
dependencies (here: project A). Leiningen seems to do that.

With regard to the new idea slowing down some features: Couldn't we have some 
kind of Leiningen service which CCW queries for all those tasks without any 
startup penalty since we can start it once and keep it running?
Does Leiningen have global state that would prevent such a setup?

Original comment by Gunnar.V...@googlemail.com on 27 Nov 2014 at 4:14

[GoogleCodeExporter]

yes, leiningen has global states which it tries to manage via locks.
Leiningen plugins also have so much power that they are involved in determining 
classpath, and I'm wary of letting them play with the Eclipse JVM, so I 
overprotect it and cherry pick inside leiningen namespaces when I can't do 
better.

Indeed, having a single service to which ccw delegates would mitigate the 
issue, and is definitely and option.

Original comment by laurent....@gmail.com on 27 Nov 2014 at 5:29