Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Fix Version/s: Initial Clearing
    • Component/s: Nexus
    • Labels:
      None

      Description

      The Apache Nexus repo contains two entries for Commons IO 1.3.2.

      The correct entry is under

      https://repository.apache.org/content/groups/public/commons-io/commons-io/

      There is also a spurious entry under

      https://repository.apache.org/content/groups/public/org/apache/commons/commons-io/

      which should never have been deployed, as the path does not match the co-ordinates.

      Please can the incorrect entry be removed? Thanks.

      See also: IO-347 and https://issues.sonatype.org/browse/MVNCENTRAL-244

        Issue Links

          Activity

          Hide
          Brian Fox added a comment -
          org.apache.commons IS the correct place for this stuff to be migrating. Any ETA on when that is going to happen? The reason Nexus didn't stop you is exactly because org.apache.commons.* is owned by the commons group and you can deploy there freely.
          Show
          Brian Fox added a comment - org.apache.commons IS the correct place for this stuff to be migrating. Any ETA on when that is going to happen? The reason Nexus didn't stop you is exactly because org.apache.commons.* is owned by the commons group and you can deploy there freely.
          Hide
          Brian Fox added a comment -
          Removed from the repo. Really need to get commons into the right group id....
          Show
          Brian Fox added a comment - Removed from the repo. Really need to get commons into the right group id....
          Hide
          Matt Benson added a comment -
          Brian: The Commons PMC hadn't been aware that there was any rush on switching to oac for a given component. Typically we'd been waiting until API incompatibilities forced a new group/artifact combination to permit otherwise incompatible versions to live in the same classloader, and we try to preserve backward compatibility between versions whenever possible.
          Show
          Matt Benson added a comment - Brian: The Commons PMC hadn't been aware that there was any rush on switching to oac for a given component. Typically we'd been waiting until API incompatibilities forced a new group/artifact combination to permit otherwise incompatible versions to live in the same classloader, and we try to preserve backward compatibility between versions whenever possible.
          Hide
          Sebb added a comment -
          <qote>The reason Nexus didn't stop you is exactly because org.apache.commons.* is owned by the commons group and you can deploy there freely. </quote>

          Does that mean that Nexus does not check that the coordinates match the path?
          If so, then that really ought to be fixed ASAP otherwise the same may happen again.

          [In this case, AFAIK the jar was uploaded prior to Nexus.]

          <quote>Really need to get commons into the right group id.... </quote>
          The reason Commons has not migrated all components to o.a.c is still the same as reported previously in other Commons/Nexus issues.

          The groupId can only be changed if the package name is changed (and vice-versa).
          This is because Maven redirection poms only work if the build reads the redirect pom, which is not guaranteed.

          Changing the package name obviously breaks binary & source compatibility so is not undertaken lightly.
          Show
          Sebb added a comment - <qote>The reason Nexus didn't stop you is exactly because org.apache.commons.* is owned by the commons group and you can deploy there freely. </quote> Does that mean that Nexus does not check that the coordinates match the path? If so, then that really ought to be fixed ASAP otherwise the same may happen again. [In this case, AFAIK the jar was uploaded prior to Nexus.] <quote>Really need to get commons into the right group id.... </quote> The reason Commons has not migrated all components to o.a.c is still the same as reported previously in other Commons/Nexus issues. The groupId can only be changed if the package name is changed (and vice-versa). This is because Maven redirection poms only work if the build reads the redirect pom, which is not guaranteed. Changing the package name obviously breaks binary & source compatibility so is not undertaken lightly.
          Hide
          Brian Fox added a comment -
          {quote}
          Does that mean that Nexus does not check that the coordinates match the path?
          If so, then that really ought to be fixed ASAP otherwise the same may happen again.
          {quote}
          This is how it is configured for every apache project, we don't need to make configuration for every sub group in here and particularly for commons, there are a bunch of them.

          {quote}
          The groupId can only be changed if the package name is changed (and vice-versa).
          This is because Maven redirection poms only work if the build reads the redirect pom, which is not guaranteed.
          {quote}


          I don't understand the connection here. There's no need to change the java package simply because the groupId has been moved. It's a nice convention yes, but not strictly required.
          Show
          Brian Fox added a comment - {quote} Does that mean that Nexus does not check that the coordinates match the path? If so, then that really ought to be fixed ASAP otherwise the same may happen again. {quote} This is how it is configured for every apache project, we don't need to make configuration for every sub group in here and particularly for commons, there are a bunch of them. {quote} The groupId can only be changed if the package name is changed (and vice-versa). This is because Maven redirection poms only work if the build reads the redirect pom, which is not guaranteed. {quote} I don't understand the connection here. There's no need to change the java package simply because the groupId has been moved. It's a nice convention yes, but not strictly required.
          Hide
          Sebb added a comment -
          Thanks for removing the jar files; however there is still an empty path:

          The URL

          https://repository.apache.org/content/groups/public/org/apache/commons/commons-io/1.3.2/

          reports 404 Not Found although it is still visible here:

          https://repository.apache.org/content/groups/public/org/apache/commons/commons-io/

          Please also remove the latter (and the nested hashes). Thanks.
          Show
          Sebb added a comment - Thanks for removing the jar files; however there is still an empty path: The URL https://repository.apache.org/content/groups/public/org/apache/commons/commons-io/1.3.2/ reports 404 Not Found although it is still visible here: https://repository.apache.org/content/groups/public/org/apache/commons/commons-io/ Please also remove the latter (and the nested hashes). Thanks.
          Hide
          Sebb added a comment -
          {quote}This is how it is configured for every apache project, we don't need to make configuration for every sub group in here and particularly for commons, there are a bunch of them.{quote}

          The coordinates and path have a well-known 1-1 relationship; Nexus could and should check this for all staging deployments.
          The relationship is the same for all Maven poms, so should not need special config.

          {quote}There's no need to change the java package simply because the groupId has been moved.{quote}
          Yes, there is.

          Maven uses the groupId:artifactId pair to determine which jars are the same (pace the version), and only allows one instance of each pair on the classpath.

          If we released an updated version (same package) of Commons IO with a different groupId, Maven would allow it to co-exist with an earlier version.
          That causes all sorts of problems.

          Redirection poms don't solve the issue.
          Show
          Sebb added a comment - {quote}This is how it is configured for every apache project, we don't need to make configuration for every sub group in here and particularly for commons, there are a bunch of them.{quote} The coordinates and path have a well-known 1-1 relationship; Nexus could and should check this for all staging deployments. The relationship is the same for all Maven poms, so should not need special config. {quote}There's no need to change the java package simply because the groupId has been moved.{quote} Yes, there is. Maven uses the groupId:artifactId pair to determine which jars are the same (pace the version), and only allows one instance of each pair on the classpath. If we released an updated version (same package) of Commons IO with a different groupId, Maven would allow it to co-exist with an earlier version. That causes all sorts of problems. Redirection poms don't solve the issue.
          Hide
          Brian Fox added a comment -
          Ok I found and removed that extra entry (the checksum for merged metadata was cached in the group repo)

          And I get your explanation about the package and groupId synchronization, makes sense.

          Show
          Brian Fox added a comment - Ok I found and removed that extra entry (the checksum for merged metadata was cached in the group repo) And I get your explanation about the package and groupId synchronization, makes sense.

            People

            • Assignee:
              Unassigned
              Reporter:
              Sebb
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development