I've had a chance to digest this now.
I need some use cases to work off of, this starting to get confusing.
Would you be willing to help out in creating a few?
I'm looking for the following.
[request] ->[archiva] -> [managed repo] -> [proxy connector] -> [remote
repo]
[request] is the full url being requested.
this request section should have in it what is expected to be
returned.
[archiva] is the configuration for archiva (specifically the base url,
and archiva version)
[managed repo] is the configuration of the repo in archiva (complete
with layout type)
managed repo specifics should also include some details of
what is stored.
[proxy connector] is the proxy connector settings/configuration.
[remote repo] is the remote repository configuration.
some details about the content in the remote repo would be
useful here.
That way I should be able to set up a few unit tests to help replicate
this issue better.
Also, can making a fast fail for this situation based on the pom
information for the same legacy artifact help?
In other words, if a request is due out to a remote repo, can we just
take the path and do a pom substitution, download / read that pom, then
know the correct artifact reference parts?
- Joakim
nicolas de loof wrote:
I made some experiment to refactor BidirectionalRepositoryLayout so
that toArtifactReference return a set of possible ArtifactReference.
This has many impacts, and sometime breaks archiva logic :
for example, what should be done in MetadataUpdaterConsumer ? We can't
create phantom metadatas just because M1 repository has non
deterministic layout !
The only way to avoid toArtifactReference to return multiple choice is
to move the connectors fetch inside, so that it can check for any
possible artifact:version before returning. But this breaks the
LegacyBidirectionalRepositoryLayout role and create a cycle between
proxy and repository-layer...
Maybe we could use an (optional) callback on toArtifactReference() to
validate the proposed reference is valid :
BidirectionalRepositoryLayout.toArtifactReference( String path,
ArtifactReferenceChecker check );
Using this, we could refactor ProxiedDavServer this way :
artifact = resourceLayout.toArtifactReference( resource,
new ArtifactReferenceChecker()
{
public boolean isValid( ArtifactReference reference )
{
applyServerSideRelocation( reference );
File resolved = connectors.fetchFromProxies(
managedRepository, reference );
return resolved != null;
}
});
Based on this, the LegacyRepositoryBidirectionalLayout can itself
maintain a set of exceptions to its artifactId:version resolution
strategy. This still requires some way to persist this info.
2007/9/27, nicolas de loof <[EMAIL PROTECTED]>:
I've attached a patch to MRM-517 : it adds an optional proposedVersion
parameter to splitFilename (method with 2 params is keeped for
compatibility)
I also added a testcase based on the Jira example.
2007/9/27, nicolas de loof <[EMAIL PROTECTED]>:
I investigate the MRM-517 issue :
"/org/hibernate/jtidy/r8-21122004/jtidy-r8-21122004.jar"
The DefaultBidirectionalRepositoryLayoutrecognizes the request to be a
well formed m2, but it fails on sanity cheks (line 255) :
// Sanity Checks.
if ( prefs.fileParts != null )
{
/* Compare artifact version to path baseversion.
*
* Version naming in the wild can be strange at times.
* Sometimes what is seen as a classifier is actually part
of the version id.
*
* To compensate for this, the path is checked against the
artifact.version and
* the concatenation of the artifact.version + "-" +
artifact.classifier
*/
...
The version part found by RepositoryLayoutUtils.splitFilename() does
not include the "r8" in the version, as it is not a valid
versionKeyword.
Same for the fop example : "trunk" is not a valid versionKeyword
Just two questions :
- is this sanity check really usefull to parse a m2 request path ?
- if so, should we
- improve RepositoryLayoutUtils.splitFileName to get an optional
possibleVersion argument ?
- apply the strategy of multiple artifactId/version for 1 request ?
Nico.
The path is recognized as beeign a well formed m2 request, but the
toPathReferences throws an exception as it doesn't recognize the
version used in the filename : RepositoryLayoutUtils.splitFilename
does not recognize "r8" as a valid versionKeyword.
2007/9/27, nicolas de loof <[EMAIL PROTECTED]>:
Second part is to dive deeper when working with legacy paths to request
the pom for the same resource path and utilize the information present
in that pom to better determine the correct artifactId / version that
the original author intended.
I just don't understand : if the requested artifact & pom is stored in
a m2-layout repository, we cannot just replace the extention with
"pom" to get it, we still need to build a valid m2 path.
The pom is allready requested by the server-side relocation, but this
can only occurs after the artifactId has been resolved.
Nico.
--
- Joakim Erdfelt
[EMAIL PROTECTED]
Open Source Software (OSS) Developer
