tags:

views:

48

answers:

3

Project structure is:

/foo
  pom.xml
  /foo-war
    pom.xml
  /foo-ear
    pom.xml

This is my parent pom.xml:

..
<modules>
  <module>foo-war</module>      
  <module>foo-ear</module>
</modules>
..

This is the content of foo-ear/pom.xml:

..
<dependencies>
    <dependency>
        <groupId>${project.groupId}</groupId>
        <artifactId>foo-war</artifactId>
        <type>war</type>
        <version>${project.version}</version>
    </dependency>
</dependencies>
..

Compilation fails with this message:

...
[INFO] Failed to resolve artifact.
Missing:
—————
1) com.foo:foo-war:war:1.0-SNAPSHOT
Try downloading the file manually from the project website.
...

Looks like foo-ear is trying to resolve the artifact when it's not ready yet. How can I instruct maven to work with foo-war beforehand? Or I'm missing something?

ps. Everything is fixed when I remove this code from parent pom.xml:

<build>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-javadoc-plugin</artifactId>
        <version>${javadoc.version}</version>
        <executions>
            <execution>
                <phase>compile</phase>
                <goals>
                   <goal>aggregate</goal>
                </goals>
            </execution>
        </executions>
    </plugin>
</build>

Why?

+3  A: 

Maven automatically resolves dependencies between modules and builds them in the correct order (At least if you are using a fairly current version), but only if you build from the parent project.

If this does not work, then probably the module is not identical to the referenced dependency (e.g. the versions don't match).

Please compare <groupId>, <artifactId>, <version>, <packaging>/<type> of

a) the dependency block in the ear and

b) the pom header of the war

seanizer
+1  A: 

It looks as though are setup correctly above. It doesn't look like a build order issue.

When you run from your top level, Maven will output the reactor build order, e.g:

[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   foo-ear
[INFO]   foo-war

Does this look OK?

Are you also definetly building 1.0-SNAPSHOT in your WAR pom? What happens if you navigate to foo-war and 'mvn install' that and then attempt to build from the top level?

I isolated the problem, and changed the question (see above)
Vincenzo
+2  A: 

Everything is fixed when I remove this code from parent pom.xml (...)

The problem looks similar to MJAVADOC-161 and more generally MJAVADOC-137. Could you be using a buggy version of the maven-javadoc-plugin like 2.3 (sadly, you're not showing it)? If yes, try with version 2.4 or another more recent version. And if you are using a version greater than 2.4, try with the version 2.4 to see if a regression was introduced at some point. And in this case, please open a new issue.


I'm using version 2.5. When I'm trying to reverse back to 2.4 I'm getting: 'aggregate' was specified in an execution, but not found in the plugin. Looks like 2.5 is my only option? You think I need to file a bug report?

I didn't pay attention to the goal, javadoc:aggregate has been introduced in version 2.5 so it won't be in 2.4 indeed and the issues mentioned above aren't relevant.

But I took a second look and I saw some others like MJAVADOC-275 or MJAVADOC-276. I'm not sure to understand the exact status (and the bug might be not fixed) but before opening an issue, be sure to try with versions 2.7 and version 2.6 (some people mention a regression introduced in 2.6.1).

Pascal Thivent
I'm using version 2.5. When I'm trying to reverse back to 2.4 I'm getting: `'aggregate' was specified in an execution, but not found in the plugin`. Looks like 2.5 is my only option? You think I need to file a bug report?
Vincenzo
@Vincenzo See my update.
Pascal Thivent
@Pascal The same story with 2.6 and 2.7 :(
Vincenzo
@Vincenzo I'm afraid the problem is not fixed then and you should probably open an issue (with a simple project demonstrating the behavior). And don't hesitate to link to existing one marked as closed.
Pascal Thivent
@Pascal I see that MJAVADOC-275 is reported as closed, while the problem still exists. Do you know what is possible to do in this case? If I open another issue in their JIRA bug tracking they will just close it as "duplicated" (as they did with MJAVADOC-276. What would you suggest?
Vincenzo
@vincenzo Post a comment (as you did), attach a zipped project allowing to reproduce the issue (you can still do it) and ask people to reopen the issue (unless they want you to create a new one). But attach a project demonstrating the issue.
Pascal Thivent