When Maven runs Java 6, maven-metadata.xml file is "corrupted"

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Duplicate
  • Affects Version/s: 2.0.4
  • Fix Version/s: 2.0.6
  • Component/s: Artifacts and Repositories
  • Labels:
    None
  • Complexity:
    Intermediate

Description

When you run Maven under Java 6, the "maven-metadata.xml" file that gets written to the remote repository is markedly different from the one generated under Java 5 and earlier. This file is "corrupted" in the sense that Maven reports errors about it, and might not be able to locate snapshots as a result. See attachment for an example file; you'd expect to see build numbers or -SNAPSHOTs, but not both at once.

This issue is described further at http://www.nabble.com/Maven-and-JDK-1.6-t3060866s177.html (originally message only, not the followups). This might be related to MNG-2709, but I don't think it's a duplicate, as it has nothing to do with testing or parents.

Issue Links

duplicates

Bug - A problem which impairs or prevents the functions of the product. MNG-2793 Snapshot plugins cannot be resolved correctly with java6

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Bug - A problem which impairs or prevents the functions of the product. MNG-2709 Maven 2 doesn't resolve parent test dependencies when using JDK 6

  • 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
Matthew Beermann added a comment -

Daniel Kulp adds:

No. It's really not corrupted despite the error. I've been tracing through
the maven code and there are a series of "transforms" (not xml transforms)
that an artifact goes through to be resolved. With Java 5, the order is:

org.apache.maven.artifact.transform.LatestArtifactTransformation
org.apache.maven.artifact.transform.ReleaseArtifactTransformation
org.apache.maven.artifact.transform.SnapshotTransformation

but with Java 6, for some reason, the order is:

org.apache.maven.artifact.transform.SnapshotTransformation
org.apache.maven.artifact.transform.LatestArtifactTransformation
org.apache.maven.artifact.transform.ReleaseArtifactTransformation

The LatestArtifactTransform is what uses to the metadata to determine
the "actual" version number (for the install plugin, 2.2-SNAPSHOT). The
SnapshotTransform then converts that to 2.2-20061118.060401-2 which is what
is then downloaded. However, in the java 6 case, the SnapshotTransform is
run first and since the version is not a "SNAPSHOT" version number, it
doesn't do any processing so then the downloading ends up looking for
2.2-SNAPSHOT, not the full version, which then fails.

I'm not sure why the order of the transforms is different yet.

Dan

Show
Matthew Beermann added a comment - Daniel Kulp adds: No. It's really not corrupted despite the error. I've been tracing through the maven code and there are a series of "transforms" (not xml transforms) that an artifact goes through to be resolved. With Java 5, the order is: org.apache.maven.artifact.transform.LatestArtifactTransformation org.apache.maven.artifact.transform.ReleaseArtifactTransformation org.apache.maven.artifact.transform.SnapshotTransformation but with Java 6, for some reason, the order is: org.apache.maven.artifact.transform.SnapshotTransformation org.apache.maven.artifact.transform.LatestArtifactTransformation org.apache.maven.artifact.transform.ReleaseArtifactTransformation The LatestArtifactTransform is what uses to the metadata to determine the "actual" version number (for the install plugin, 2.2-SNAPSHOT). The SnapshotTransform then converts that to 2.2-20061118.060401-2 which is what is then downloaded. However, in the java 6 case, the SnapshotTransform is run first and since the version is not a "SNAPSHOT" version number, it doesn't do any processing so then the downloading ends up looking for 2.2-SNAPSHOT, not the full version, which then fails. I'm not sure why the order of the transforms is different yet. Dan
Hide
Permalink
Jeremy Norris added a comment -

Are there any workarounds for this without reverting to java 5?

Show
Jeremy Norris added a comment - Are there any workarounds for this without reverting to java 5?
Hide
Permalink
Matthew Beermann added a comment -

Duplicate of MNG-2793.

Show
Matthew Beermann added a comment - Duplicate of MNG-2793.

People

  • Assignee:
    Unassigned
    Reporter:
    Matthew Beermann
Vote (4)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: