Uploaded image for project: 'Maven'
  1. Maven
  2. MNG-5368

UnsupportedOperationException thrown when version range is not correct in dependencyManagement definitions

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.4
    • Fix Version/s: 3.5.0-alpha-1, 3.5.0
    • Component/s: POM
    • Labels:
      None
    • Environment:
      MacOS 10.7.5 Darwin Kernel Version 11.4.2: xnu-1699.32.7~1/RELEASE_X86_64 x86_64

      Description

      When specifying a non valid version range in a dependencyManagement tag, instead of a descriptive error message we get a UnsupportedOperationException thrown. The code at fault in org.apache.maven.project.MavenProject#getManagedVersionMap is:

      map = new HashMap<String, Artifact>();
                      for ( Iterator<Dependency> i = dependencyManagement.getDependencies().iterator(); i.hasNext(); )
                      {
                          Dependency d = i.next();
      
                          Artifact artifact = repositorySystem.createDependencyArtifact( d );
      
                          if ( artifact == null )
                          {
                              map = Collections.emptyMap();
                          }
      
                          map.put( d.getManagementKey(), artifact );
      

      When the artifact is null, the map is set to an immutable map and then the null artifact is then attempted to be put into it. This will always fail. This particular problem originates from code further down the stack in org.apache.maven.repository.legacy.LegacyRepositorySystem:

         public Artifact createDependencyArtifact( Dependency d )
          {
              VersionRange versionRange;
              try
              {
                  versionRange = VersionRange.createFromVersionSpec( d.getVersion() );
              }
              catch ( InvalidVersionSpecificationException e )
              {
                  return null;
              }
      
      

      Instead of signalling appropriately that an error has occurred, this exception is consumed and thus causes the erroneous behaviour mentioned in the first code snippet

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                schulte77 Christian Schulte
                Reporter:
                ajh21 Andrew Haines
              • Votes:
                0 Vote for this issue
                Watchers:
                5 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: