Archiva

empty metadatas frmo a repository group

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1
  • Fix Version/s: 1.1
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

Here is my configuration :

 
group repository "maven"
  +-- managed repository "releases"
        +-- proxy connector to central
        +-- proxy connector to dev.java.net
        +-- proxy connector to jboss ...
  +-- managed repository "private"
        +-- proxy connector to corporate repository
        +-- proxy connector to second corporate repository

From a fresh new install, requesting "mvn eclipse:eclipse" fails with error :
No versions are present in the repository for the artifact with a range [3.1.0,4.0.0)
org.eclipse.core:resources:jar:null

Browsing archvia/repository/maven/org/eclipse/core/resources/maven-metadata.xml returns a metadatafile with no entry.

The metadata file in the "releases" repo (that merges all connectors metadatas) is correct with the expected versions available from central.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
nicolas de loof added a comment -

"empty" here is not for "blank", but for XML root with no child element.

The issue depends on the repository ordering in the group. The "first win" logic returns an empty metadata because the first repository didn't found the artifact with its proxies and created an empty metadata file. This may be considered to be a bug...

In any way, we MUST support metadatas merge for this use case :

A user has an issue with a maven plugin. As a nice guy, he creates an issue, attach a patch, but to get quick fix he deploys a snapshot to its corporate repo.

To get it using a group repository ("public" proxying public repos + "corporate"), we need to merge the metadatas from both repositories, so that the custom snapshot will get listed in metadatas + all available version on public snapshot repositories.

Show
nicolas de loof added a comment - "empty" here is not for "blank", but for XML root with no child element. The issue depends on the repository ordering in the group. The "first win" logic returns an empty metadata because the first repository didn't found the artifact with its proxies and created an empty metadata file. This may be considered to be a bug... In any way, we MUST support metadatas merge for this use case : A user has an issue with a maven plugin. As a nice guy, he creates an issue, attach a patch, but to get quick fix he deploys a snapshot to its corporate repo. To get it using a group repository ("public" proxying public repos + "corporate"), we need to merge the metadatas from both repositories, so that the custom snapshot will get listed in metadatas + all available version on public snapshot repositories.
Hide
Permalink
Maria Odea Ching added a comment -

Added code for merging the metadatas of the repos under a repo group into one metadata in trunk -r676322.

Show
Maria Odea Ching added a comment - Added code for merging the metadatas of the repos under a repo group into one metadata in trunk -r676322.
Hide
Permalink
Maria Odea Ching added a comment - - edited

Additional fixes in trunk -r676516:

  1. generate checksums for the generated merged metadata
  2. put the merged metadata & its checksums in the first repo where the metadata was found (with the filename: merged-maven-metadata.xml)
  3. merge the metadata if and only if all the following conditions are met:
    • the request was made to a repository group url
    • the requested resource is a metadata file or a checksum file of a metadata
    • the requested metadata file is at the project level, not version level
  4. added test case when metadata checksums are requested after the metadata file (simulate Maven requests)
Show
Maria Odea Ching added a comment - - edited Additional fixes in trunk -r676516:
  1. generate checksums for the generated merged metadata
  2. put the merged metadata & its checksums in the first repo where the metadata was found (with the filename: merged-maven-metadata.xml)
  3. merge the metadata if and only if all the following conditions are met:
    • the request was made to a repository group url
    • the requested resource is a metadata file or a checksum file of a metadata
    • the requested metadata file is at the project level, not version level
  4. added test case when metadata checksums are requested after the metadata file (simulate Maven requests)
Hide
Permalink
Maria Odea Ching added a comment - - edited

Additional fix in -r676526:

  • write the merged metadata into a file named maven-metadata-${repoGroupId}.xml instead of merged-maven-metadata.xml to handle instances when a repository belongs to multiple groups.

Could anyone please verify the above fixes too? I already tested it, but I might have missed something..
Thanks!

Show
Maria Odea Ching added a comment - - edited Additional fix in -r676526:
  • write the merged metadata into a file named maven-metadata-${repoGroupId}.xml instead of merged-maven-metadata.xml to handle instances when a repository belongs to multiple groups.
Could anyone please verify the above fixes too? I already tested it, but I might have missed something.. Thanks!

People

Vote (1)
Watch (1)

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.