Maven 2 & 3

this is my set of POM tests, in addition to the unit tests I've put in SVN, to verify that I cannot reproduce this issue.

I visually inspected the POM resulting from a build of the bottom project using:

mvn help:effective-pom

I also made a point of executing:

mvn -N install

on both of the parent dirs, and moving the bottom project out to a different directory structure, then trying again, just to be sure it wasn't related to a resolution problem when the parent POMs were in the repository.

I cannot reproduce this issue, either with the additional unit tests I added directly for the DefaultModelInheritanceAssembler, or using the project tests that I've attached to this issue.

I still have this issue:

The parent pom:

<dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<version>2.3</version>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>5.1</version>
<scope>test</scope>
<classifier>jdk14</classifier> <--- this causes troubles
</dependency>
</dependencies>
</dependencyManagement>

The child pom:

<dependencies>
<dependency>
<groupId>commons-lang</groupId>
<artifactId>commons-lang</artifactId>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
</dependency>
</dependencies>

Running it:

+ Error stacktraces are turned on.
Maven version: 2.0.5
[DEBUG] Building Maven user-level plugin registry from: 'D:\Documents and Settings\t277922\.m2\plugin-registry.xml'
[DEBUG] Building Maven global-level plugin registry from: 'D:\Data\t277922\maven-2.0.5\bin\..\conf\plugin-registry.xml'
[INFO] Scanning for projects...
[DEBUG] Searching for parent-POM: com.xxx.swidCTZ.v1.projectgenerator:CTZ_1_ProjectGeneratorBuild::1.0.0-SNAPSHOT of project: com.xxx.swidCTZ.v1.projectgenerator:CTZ_1_ProjectGeneratorJava:jar:1.0.0-SNAPSHOT in relative path: ../CTZ_1_ProjectGeneratorBuild/pom.xml
[DEBUG] Using parent-POM from the project hierarchy at: '../CTZ_1_ProjectGeneratorBuild/pom.xml' for project: com.xxx.swidCTZ.v1.projectgenerator:CTZ_1_ProjectGeneratorJava:jar:1.0.0-SNAPSHOT
[DEBUG] Searching for parent-POM: com.xxx.CTZ:CTZ_1_I2U8Pom::1.0.0 of project: com.xxx.swidCTZ.v1.projectgenerator:CTZ_1_ProjectGeneratorBuild:pom:1.0.0-SNAPSHOT in relative path: ../pom.xml
[DEBUG] Parent-POM: com.xxx.CTZ:CTZ_1_I2U8Pom::1.0.0 not found in relative path: ../pom.xml
[DEBUG] Retrieving parent-POM: com.xxx.CTZ:CTZ_1_I2U8Pom::1.0.0 for project: com.xxx.swidCTZ.v1.projectgenerator:CTZ_1_ProjectGeneratorBuild:pom:1.0.0-SNAPSHOT from the repository.
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).

Project ID: com.xxx.swidCTZ.v1.projectgenerator:CTZ_1_ProjectGeneratorJava
POM Location: D:\Data\Rad\t277922\Projektgenerator\CTZ_1_ProjectGeneratorJava\pom.xml
Validation Messages:

[0] 'dependencies.dependency.version' is missing for org.testng:testng

Reason: Failed to validate POM

[INFO] ------------------------------------------------------------------------
[DEBUG] Trace
org.apache.maven.reactor.MavenExecutionException: Failed to validate POM
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:373)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:286)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60)
at java.lang.reflect.Method.invoke(Method.java:391)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to validate POM
at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:949)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:760)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:431)
at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:195)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:523)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:455)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:359)
... 12 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Tue Mar 20 11:31:54 CET 2007
[INFO] Final Memory: 2M/6M
[INFO] ------------------------------------------------------------------------

If I just declare the dependency in the child pom, it works (with the classifier). But as soon as I add the classifier tag in the parent, it stopps working.

Maven is right, since in your child POM you address a different artifact for TestNG (the artifact without a classifier). The classifier is part of the artifact selection, it is nothing that can be omitted.

Ok I see. I just wondering about this behavour, since in my opinion the classifier has a smaller impact than the version. If you look at the definition of a dependency:

<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>5.1</version>
<scope>test</scope>
<classifier>jdk14</classifier>
</dependency>

With the classifier you declare to stick with version 5.1, but with a special kind of this version.
testng-5.1.jar --> testng-5.1-jdk14.jar

The same applies to javadoc and sources (if you upload javadocs and sources with deploy:deploy-file).

But maven behaves (what you are saying) different in the case of dependency resolution (at least in reactor builds). The classifier is on the same level as groupId and artifactId. This is different from the view of the repository hierarchy.

With the classifier you declare a secondary (aka attached), but different artifact. It is not even necessary to have a main artifact. There's no difference in this respect with the dependency resolution nor the repo.

You might be confused, since some plugins resolve those secondary artifacts on their own, even if they are not declared in the dependency section itself, e.g. the Eclipse plugin looks automatically for all declared and transitive dependencies for the appropriate source artifact (for downloadSources=true), but this is the plugin's task and has nothing to do with the dependency mechanism per se.

In your case you try to add the attached artifact to the standard dependency mechanism and therefore you have to declare the classifier, since the compiler plugin does not look for undeclared attached artifacts on its own.