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 Thu, 27 Sep 2007 09:36:57 GMT
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