Reactor projects sometimes used even with version mismatch

Details

  • Complexity:
    Expert
  • Testcase included:
    yes

Description

See attached sample project structure.

In short: project A depends on project B version 1.1-SNAPSHOT,
but only 1.0-SNAPSHOT is available (both in the reactor, so on disk), as well
as in the local repository.

Still, m2 install runs fine. Excerpt from building Project A:

[DEBUG] Artifact not found - using stub model: Unable to download the artifact from any repository
test:sub-b:1.1-SNAPSHOT:pom

......configuring compiler plugin.....

[DEBUG] (f) classpathElements = [/mnt/a/home/forge/work/sandbox/m2test/deptest/sub-a/target/classes, /mnt/a/home/forge/work/sandbox/m2test/deptest/sub-b/target/classes]

Now, when running m2 eclipse:eclipse, m2 reacts as it should. Still the pom stub-model is used,
but the .jar cannot be resolved.
(weird enough m2 eclipse:eclipse doesn't accept reactor dependencies during resolve,
although the generated projects do have internal links - but this is a different bug; this is a convenient bug for now.. )

Proposed fix: Reactor projects can only be used when the pom versions match too. I thought
this code was in months ago and working properly.

  1. File
    deptest.tgz
    20/Oct/05 4:49 AM
    1 kB
    Kenney Westerhof
  3. Text File
    MNG-1245.patch
    09/Jun/06 11:15 AM
    1 kB
    Mike Perham

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. MECLIPSE-123 Transitive deps with wrong version partly resolved to reactor resulting in 2 absolute paths being concatenated

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-2787 Multi Project Aggregator ignoring dependency version in the POM

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is duplicated by

Bug - A problem which impairs or prevents the functions of the product. MEJB-18 Manifest classpath contains wrong entries in multi-module build

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-2424 Classpath in reactor builds differ from dependency resolution

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. MNG-1975 EAR project depends on WAR that doesn't exist, but it builds succesfully

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

will investigate.

Show
John Casey added a comment - will investigate.
Hide
Permalink
Mike Perham added a comment -

The code in question appears to be in MavenProject.replaceWithActiveArtifact: Note it should probably be doing some version checking also.

public Artifact replaceWithActiveArtifact( Artifact pluginArtifact )
    {
        if ( getProjectReferences() != null && !getProjectReferences().isEmpty() )
        {
            // TODO: use MavenProject getProjectReferenceId
            String refId = ArtifactUtils.versionlessKey( pluginArtifact.getGroupId(), pluginArtifact.getArtifactId() );
            MavenProject ref = (MavenProject) getProjectReferences().get( refId );
            if ( ref != null && ref.getArtifact() != null )
            {
                // TODO: if not matching, we should get the correct artifact from that project (attached)
                if ( ref.getArtifact().getDependencyConflictId().equals( pluginArtifact.getDependencyConflictId() ) )
                {
                    // if the project artifact doesn't exist, don't use it. We haven't built that far.
                    if ( ref.getArtifact().getFile() != null && ref.getArtifact().getFile().exists() )
                    {
                        pluginArtifact = new ActiveProjectArtifact( ref, pluginArtifact );
                    }
...SNIP...
                }
            }
        }
        return pluginArtifact;
    }
Show
Mike Perham added a comment - The code in question appears to be in MavenProject.replaceWithActiveArtifact: Note it should probably be doing some version checking also. 
public Artifact replaceWithActiveArtifact( Artifact pluginArtifact )
    {
        if ( getProjectReferences() != null && !getProjectReferences().isEmpty() )
        {
            // TODO: use MavenProject getProjectReferenceId
            String refId = ArtifactUtils.versionlessKey( pluginArtifact.getGroupId(), pluginArtifact.getArtifactId() );
            MavenProject ref = (MavenProject) getProjectReferences().get( refId );
            if ( ref != null && ref.getArtifact() != null )
            {
                // TODO: if not matching, we should get the correct artifact from that project (attached)
                if ( ref.getArtifact().getDependencyConflictId().equals( pluginArtifact.getDependencyConflictId() ) )
                {
                    // if the project artifact doesn't exist, don't use it. We haven't built that far.
                    if ( ref.getArtifact().getFile() != null && ref.getArtifact().getFile().exists() )
                    {
                        pluginArtifact = new ActiveProjectArtifact( ref, pluginArtifact );
                    }
...SNIP...
                }
            }
        }
        return pluginArtifact;
    }
Hide
Permalink
Mike Perham added a comment -

2.0.x patch which adds version checking so the project reference is only used if the versions are the same. The full build of components passes with this patch.

Show
Mike Perham added a comment - 2.0.x patch which adds version checking so the project reference is only used if the versions are the same. The full build of components passes with this patch.
Hide
Permalink
Mike Perham added a comment -

Patched binary. No warranties.

Show
Mike Perham added a comment - Patched binary. No warranties.
Hide
Permalink
Olivier Lamy added a comment -

The question is : is it a bug or a feature ? ( )

Show
Olivier Lamy added a comment - The question is : is it a bug or a feature ? ( )
Hide
Permalink
Kenney Westerhof added a comment -

Fixed in svn trunk revision 413054.
Applied to the maven-2.0.x branch in revision 419630.

Show
Kenney Westerhof added a comment - Fixed in svn trunk revision 413054. Applied to the maven-2.0.x branch in revision 419630.

People

  • Assignee:
    Kenney Westerhof
    Reporter:
    Kenney Westerhof
Vote (1)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
2h
Original Estimate - 2 hours
Remaining:
2h
Remaining Estimate - 2 hours
Logged:
Not Specified
Time Spent - Not Specified