Building fails because of Inconsistent reactor project

[Zegveld]

When building our project including product the build crashes with the following error:

[ERROR] Failed to execute goal org.eclipse.tycho:target-platform-configuration:4.0.6:target-platform (default-target-platform) 
.....
Caused by: java.lang.IllegalStateException: Inconsistent reactor project at location ....\presentatie\presentatie\target\caris.presentatie-4.1.12-SNAPSHOT.jar. null is not the same as MavenProject: nl.loxia.caris:caris.presentatie:4.1.12-SNAPSHOT @ ....\presentatie\presentatie\.tycho-consumer-pom.xml
    at org.eclipse.tycho.core.osgitools.targetplatform.ArtifactCollection.registerArtifactLocation (ArtifactCollection.java:187)
    at org.eclipse.tycho.core.osgitools.targetplatform.ArtifactCollection.addArtifact (ArtifactCollection.java:155)
    at org.eclipse.tycho.core.osgitools.targetplatform.ArtifactCollection.addArtifact (ArtifactCollection.java:73)
    at org.eclipse.tycho.core.osgitools.targetplatform.ArtifactCollection.addArtifactFile (ArtifactCollection.java:64)
    at org.eclipse.tycho.p2resolver.PomUnits.lambda$addCollectedUnits$1 (PomUnits.java:98)
    at java.lang.Iterable.forEach (Iterable.java:75)
    at org.eclipse.tycho.p2resolver.PomInstallableUnitStore.addPomDependencyConsumer (PomInstallableUnitStore.java:232)
    at org.eclipse.tycho.p2resolver.PomUnits.addCollectedUnits (PomUnits.java:85)
    at org.eclipse.tycho.p2resolver.P2DependencyResolver.resolvePomDependencies (P2DependencyResolver.java:302)
    at org.eclipse.tycho.core.resolver.DefaultTargetPlatformService.lambda$computeFinalTargetPlatform$2 (DefaultTargetPlatformService.java:147)
    at org.eclipse.tycho.core.osgitools.DefaultReactorProject$LazyValue.get (DefaultReactorProject.java:307)
    at org.eclipse.tycho.core.osgitools.DefaultReactorProject.computeContextValue (DefaultReactorProject.java:200)
    at org.eclipse.tycho.core.resolver.DefaultTargetPlatformService.computeFinalTargetPlatform (DefaultTargetPlatformService.java:103)
    at org.eclipse.tycho.core.resolver.DefaultTargetPlatformService.getTargetPlatform (DefaultTargetPlatformService.java:99)
    at org.eclipse.tycho.target.TargetPlatformMojo.execute (TargetPlatformMojo.java:51)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:77)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:568)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:283)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:226)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:407)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:348)

After debugging I found the following location where the normalizedArtifact is initialized:

tycho/tycho-core/src/main/java/org/eclipse/tycho/core/osgitools/targetplatform/ArtifactCollection.java

Line 65 in b110909

addArtifact(new DefaultArtifactDescriptor(key, location, null, null, installableUnits));

Here is the location where the check exists:

tycho/tycho-core/src/main/java/org/eclipse/tycho/core/osgitools/targetplatform/ArtifactCollection.java

Lines 184 to 186 in b110909

	// sanity check, all artifacts at the same location have the same reactor project
	for (ArtifactDescriptor other : classified.values()) {
	if (!Objects.equals(normalizedArtifact.getMavenProject(), other.getMavenProject())) {

In my case the ones in classified collection know the mavenProject, and it is not null as defined for the normalizedArtifact at initialization.

The thing I can't put my finger on is why this only happens consistently for this project and not others.

Perhaps this sanity check does not make sense for cases where the normalizedArtifact.getMavenProject() is not set?
Or perhaps L65 should change into something like:

        addArtifact(new DefaultArtifactDescriptor(key, location, getMavenProject(location), null, installableUnits));

That way the mavenProject should indeed be the same value.

[laeubi]

Can you provide an integration-test to demonstrate the issue?

[Zegveld]

It took me a while but I finally figured it out.

In our build we have a couple of optional jars which we include using maven dependencies, but these depend on a reactor project. If I exclude the implicit maven dependency in the product my build succeeds again.

I've created a reproducer for this issue, there I've just directly added the dependency in the product maven project.

My situation to be exact is the following:

module gid.a.
module gid.b (depends on gid.a).
product includes gid.a, and has gid.b added as separate jar using a specific assembly configuration.

The severity for me has now decreased, because I've got a work-around:

		<dependency>
			<groupId>gid</groupId>
			<artifactId>gid.b</artifactId>
			<version>${project.version}</version>
			<type>jar</type>
			<exclusions>
				<exclusion>
					<groupId>gid</groupId>
					<artifactId>gid.a</artifactId>
				</exclusion>
			</exclusions>
		</dependency>

With that exclusion set, gid.a doesn't throw the reactor error anymore for the product.