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.
>
