Maven build : How to resolve the workspace artifacts without installing them to repo and without using m2eclipse

Question

I've worked a little with m2eclipse in Eclipse Indigo and now I'm trying to use Maven from command line without Eclipse and without m2eclipse plugin. The m2eclipse has abililty to resolve the artifacts from the workspace without installing them to repository and this feature allows me to run my build without problems in Eclipse , but in CMD I'm getting the errors of missing jars.

[WARNING] The POM for AAA_7.1.1:ConfigurationView:jar:0.0.1-SNAPSHOT is missing, no dependency information available [WARNING] The POM for AAA_7.1.1:Beans:jar:0.0.1-SNAPSHOT is missing, no dependency information available [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [ERROR] Failed to execute goal on project Client: Could not resolve dependencies for project AAA_7.1.1:Client:pom:0.0.1-SNAPSHOT:.......

Our goal is to keep the repo clean as much as possible , that's the reason why I'd like to keep it working in a such way. So my question is how to resolve the dependencies without installing them to repo and if it's possible at all?

Answer 1

IMO, the standard way to go with Maven is mvn clean install.
But if I understand well your problem, you want to keep your local repository as clean as possible ?
One way to do that would be to use multiple local repositories, but I don't think it's possible at the moment (Maven 3.0).

However you can use alternate local repo with -Dmaven.repo.local or alternate settings with mvn --settings (see answer).

See also :

• Previous question : maven workspace local repository
• JIRA : Allow multiple local repositories (Unresolved)
• Local repository separation -> workspaces don't seem to be implemented at the moment...

Answer 2

Basically you want a maven build, where the reactor contains all your 97 modules. To do this:
Create a parent, which contains all those 97 modules as children (if you are already multi module, you just need to configure the already existing parents to be the children of this new parent). Than start your build at that new parent. The convention is normally to have the parent in the upper directory. But you may also use relative paths that contain .. for the module location specification. There is also no need to inherit from the new parent in the existing parents. So you do not need to change any of the existing poms.