[
http://jira.codehaus.org/browse/MRM-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt updated MRM-463:
-------------------------------
Description:
When dealing with metadata.xml files and proxying the merging of metadata is
not performed correctly.
Often ending up with a metadata.xml file with no versions specified.
Tasks
HTML2TextReader.listItemPrefixRe-enabled metadata tests in the archiva-proxy
module.
HTML2TextReader.listItemPrefixFix the proxy code (and possibly the tests) to
ensure metadata.xml files are merged correctly.
HTML2TextReader.listItemPrefixCreate tests for 1 managed to multiple remote
repos all with metadata.xml for the same groupId:artifactId
HTML2TextReader.listItemPrefixCreate tests for versionless and versioned
metadata.xml files.
Note: Consider using the VersionComparator to obtain a unique list of sorted
(by
was:
When dealing with metadata.xml files and proxying the merging of metadata is
not performed correctly.
Often ending up with a metadata.xml file with no versions specified.
Tasks
* Re-enabled metadata tests in the archiva-proxy module.
* Fix the proxy code (and possibly the tests) to ensure metadata.xml files are
merged correctly.
* Create tests for 1 managed to multiple remote repos all with metadata.xml for
the same groupId:artifactId
* Create tests for versionless and versioned metadata.xml files.
Note: Consider using the VersionComparator to obtain a unique list of sorted
(by version) versions for the merged metadata.xml file.
There are two major things going on here.
1) The metadata.xml files need to be sane to what exists in the managed
repository.
2) The metadata.xml files need to contain the versions available at all
downstream remote repositories that are setup as proxied to this managed
repository.
And there are two uses of the metadata.xml file.
1) List of versions available for a given groupId:artifactId reference, as well
as what the current/latest version is.
2) Listing of SNAPSHOTS available in a given
groupId:artifactId:version-SNAPSHOT reference.
Question is, should the metadata.xml file returned to the client contain the
entire list of potential versions, both actual, and available to be proxied, or
just the ones that are available on the managed repository?
I vote for the entire list of potential versions from all downstream remote
repositories.
> Metadata merging doesn't work.
> ------------------------------
>
> Key: MRM-463
> URL: http://jira.codehaus.org/browse/MRM-463
> Project: Archiva
> Issue Type: Bug
> Components: remote proxy
> Affects Versions: 1.0-beta-2
> Reporter: Joakim Erdfelt
> Assignee: Joakim Erdfelt
> Priority: Blocker
> Fix For: 1.0-beta-3
>
>
> When dealing with metadata.xml files and proxying the merging of metadata is
> not performed correctly.
> Often ending up with a metadata.xml file with no versions specified.
> Tasks
> HTML2TextReader.listItemPrefixRe-enabled metadata tests in the archiva-proxy
> module.
> HTML2TextReader.listItemPrefixFix the proxy code (and possibly the tests) to
> ensure metadata.xml files are merged correctly.
> HTML2TextReader.listItemPrefixCreate tests for 1 managed to multiple remote
> repos all with metadata.xml for the same groupId:artifactId
> HTML2TextReader.listItemPrefixCreate tests for versionless and versioned
> metadata.xml files.
> Note: Consider using the VersionComparator to obtain a unique list of sorted
> (by
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
