Problems with Legacy Layout Detection (Was: Re: critical issue with 1.0-beta-2 !!!)

[Joakim Erdfelt <jo...@erdfelt.com>]

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 <ni...@gmail.com>:
>   
>> 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 <ni...@gmail.com>:
>>     
>>> 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 <ni...@gmail.com>:
>>>       
>>>>> 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
  joakim@erdfelt.com
  Open Source Software (OSS) Developer