archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nicolas de loof" <nicolas.del...@gmail.com>
Subject Re: critical issue with 1.0-beta-2 !!!
Date Fri, 28 Sep 2007 19:37:14 GMT
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 <nicolas.deloof@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 <nicolas.deloof@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 <nicolas.deloof@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.
> > >
> >
>

Mime
View raw message