How to configure a subproject dependency in Maven without deploying jars?

Question

I googled this and it seems that no one has an answer, yet it seems like such an elementary thing that it should be possible.

I have the following project structure:

Answer 1

You should have a master pom at parent's level, in which you will list the modules of your project.

  <modules>
    <module>sub-project1</module>
    <module>sub-project2</module>>
  </modules>

In each subproject you have to reference your parent:

<parent>
    <artifactId>parent</artifactId>
    <groupId>mygroup</groupId>
    <version>1.0-SNAPSHOT</version>
</parent>

And you specify the dependencies between the project just as you did. I think you've missed some of the steps I've described.

Edit: you should issue your mvn clean install at the parent level.

Answer 2

When I do this, Maven tries to dowload the sub-project1.jar file, which does not exist because it's not ready for the repo yet.

That's the normal behavior, Maven resolves dependencies through the local repository so you need to install sub-project1 first. Actually, the common way to deal with this kind of situation is to launch a reactor build (a multi-modules build) from the parent.

Assuming you are aggregating modules in the parent i.e. you have something like this declared in the "parent" pom.xml:

<modules>
  <module>sub-project1</module>
  <module>sub-project2</module>>
</modules>

Just cd into the parent directory and launch a reactor build:

$ cd parent
$ mvn install

Maven will then calculate the build order (deducted from the oriented graph made of modules and their dependencies) and run install on all modules in the calculated order (parent first, then sub-project1 and finally sub-project2 for your particular example).

But don't use a scope of type import, you are misusing it here. Remove it.

Update: The question has been updated while I was answering and the POMs shown do no illustrate the situation given in the original question (reversed dependency, probable mistake in the artifact id). But the suggested approach still applies. Remove the <scope>import</scope> on the dependency and start a reactor build from the parent.