"local" dependency resolution with non-default dependency types

[Jörg Henne <j....@levigo.de>]

Hi all,

while trying to set up a rather complex multi-project maven build, I 
have run into the problem, that I am unable to convince maven to use 
local dependencies instead of searching repositories.

This is my scenario:
- We have a multi-project build organized hierarchically
- all child projects have parent references pointing upwards
- all projects share the same group id
- one child project (I'll call it A) contains an EJB along with a set of 
test-cases
- A's maven-ejb-plugin is told to generate an  EJB client
- the A's src/test/java also contains an abstract base test class
- A's pom uses to maven-jar-plugin to package a jar of the test classes
- a second EJB project (B) also contains some test classes which inherit 
from A's base test class
- also, B's bean classes have a dependency on A
- all versions are SNAPSHOT versions.

What I'd like to attain:
- being able to build the project on a pristine system (no artifacts of 
the project are present in the local repository, no artifacts are pulled 
from a remote repository)
- being able to build it (e.g. a "test" goal) without using a previous 
"install" or something, because that would, IMHO, break the first rule

What I'm seeing:
- I'm running a top-level "mvn test", for example
- project A gets built just fine
- when I specify a dependency on A from B with type 
<type>ejb-client</type> (which should be sufficient), the build of B 
fails, because maven tries to download A-SNAPSHOT-client.jar - which is 
nowhere to be found.
- when I leave out the <type>ejb-client</type>, the classes compile Ok, 
however...
- ... the same problem comes up with B's test classes: there is no 
A-SNAPSHOT-test.jar yet, and maven doesn't try to access the plain 
compiled classes.

I'd be more than happy about hints on how this is meant to work. Or 
maybe there's a similar project setup which demonstrates this. 
Unfortunately the projects I know, e.g. Apache Directory Server, don't 
seem to suffer from the Problem of test classes depending on each other.

Thanks
Joerg Henne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org