search

eclipse-tycho / tycho

Tycho project repository (tycho)
https://tycho.eclipseprojects.io
Eclipse Public License 2.0
163 stars 188 forks source link

Building fails because of `Inconsistent reactor project` #3760

Open Zegveld opened 3 months ago

Zegveld commented 3 months ago

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: https://github.com/eclipse-tycho/tycho/blob/b110909834cc796cf8fc9fdc206b40771b71d152/tycho-core/src/main/java/org/eclipse/tycho/core/osgitools/targetplatform/ArtifactCollection.java#L65

Here is the location where the check exists: https://github.com/eclipse-tycho/tycho/blob/b110909834cc796cf8fc9fdc206b40771b71d152/tycho-core/src/main/java/org/eclipse/tycho/core/osgitools/targetplatform/ArtifactCollection.java#L184-L186

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 commented 3 months ago

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

Zegveld commented 3 months ago

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.