Maven 2 & 3

Need better handling of malformed poms in local cache, like check for an update every run

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 2.0
  • Fix Version/s: None
  • Component/s: Artifacts and Repositories
  • Labels:
    None
  • Complexity:
    Intermediate
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

If a pom has a typo in it, it is downloaded and parsed with a (misspelled) error message printed

[m2:libraries] [WARNING] POM for 'org.hibernate:hibernate-tools:pom:3.1.0.beta2' is invalid. It will be ignored for artifact resolution. Reason: Parse error reading POM. Reason: expected > to finsh end tag not < from line 7 (position: TEXT seen ...</dependency>\r\n </dependencies\r\n<... @29:2)

but if the pom is corrected in the source repository, the local system doesnt check for a change, it just goes with what is there.

Invalid pom files should be remembered and replacements looked for, because there is no value in retaining them.

Issue Links

This issue is related to:
MNG-1609 Force update of files in the repo if checksum has been updated Major Open
MAVENPROXY-36 Redownload artifacts with updated checksum Major Open
MNG-1258 Add option to redownload poms Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
ruel loehr added a comment -

Agreed, this is a problem. A user shouldn't have to wipe out things in his repo to get a pom update.

Another possible use case:

A user runs a maven build. He gets a dependency, foo.jar & foo.pom from the central repo. Now the user runs a different build for a different project, however this time the build uses a company internal repository. The internal build references foo.jar & foo.pom from the internal repo, but the internal repo's foo.pom has more information defined (e.g. a new transitive dependency, or license information) without which, the build will fail.

Show
ruel loehr added a comment - Agreed, this is a problem. A user shouldn't have to wipe out things in his repo to get a pom update. Another possible use case: A user runs a maven build. He gets a dependency, foo.jar & foo.pom from the central repo. Now the user runs a different build for a different project, however this time the build uses a company internal repository. The internal build references foo.jar & foo.pom from the internal repo, but the internal repo's foo.pom has more information defined (e.g. a new transitive dependency, or license information) without which, the build will fail.
Hide
Permalink
ruel loehr added a comment -

Patch will causes maven to look at the md5 and sha1 files in remote repo, if they differ from that in the local cache, it will then attempt to download the version from the remote repo.

Show
ruel loehr added a comment - Patch will causes maven to look at the md5 and sha1 files in remote repo, if they differ from that in the local cache, it will then attempt to download the version from the remote repo.
Hide
Permalink
ruel loehr added a comment -

I made a patch which resolves the above issue. When the defaultArtifactResolver is handed an artifact to resolve, if that artifact is already located in the local cache, it evaluates the hash values of the files compared to those in the remote repo. If the values differ it will attempt to pull down the remote artifact.

Show
ruel loehr added a comment - I made a patch which resolves the above issue. When the defaultArtifactResolver is handed an artifact to resolve, if that artifact is already located in the local cache, it evaluates the hash values of the files compared to those in the remote repo. If the values differ it will attempt to pull down the remote artifact.
Hide
Permalink
Carlos Sanchez added a comment -

This patch has a lot of formatting changes that doesn't make it very readable.

Show
Carlos Sanchez added a comment - This patch has a lot of formatting changes that doesn't make it very readable.
Hide
Permalink
Jason van Zyl added a comment -

I think the problem here is that we have POMs that are built with tools other then Maven and the POM is not validated. We don't want to have to check released POMs over and over again for changes the checking should be made upfront and

Show
Jason van Zyl added a comment - I think the problem here is that we have POMs that are built with tools other then Maven and the POM is not validated. We don't want to have to check released POMs over and over again for changes the checking should be made upfront and
Hide
Permalink
Brett Porter added a comment -

agree checking every time is bad, but we should be dealing with malformed POMs better. Happy to leave this specific one closed and leave it as an architectural goal for maven-artifact

Show
Brett Porter added a comment - agree checking every time is bad, but we should be dealing with malformed POMs better. Happy to leave this specific one closed and leave it as an architectural goal for maven-artifact

People

Vote (3)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.