You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@archiva.apache.org by nicolas de loof <ni...@gmail.com> on 2007/09/25 17:19:17 UTC
critical issue with 1.0-beta-2 !!!
I just installed beta-2 in replacement to my corporate repo.
I may had better tested it before :-(
requesting using maven1 an artifact with "-" in artifactID fails :
request for "maven/plugins/maven-test-plugin-1.8.2.jar"
in logs :
<proxied>\maven\maven\test-plugin-1.8.2\maven-test-plugin-1.8.2.jar
does not exist
The versionUtil.versionPatterns seems to grab too much tags as possible version.
I've patched it locally to remove "test[_.0-9]*" as possible version
pattern. Could we enhance this artifactId detection by ensuring ALL
tokens considered as version are valid versionElements ?
Something like this :
[- <artifactId-Element>]+ [- <versionElement>]+ [- <classifier>]?
In such case, for "maven-test-plugin-1.8.2", as "plugin" is not a
valid versionElement, "test" and "plugin" may have been added to the
artifactId
Re: critical issue with 1.0-beta-2 !!!
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
Geez. my very first sentence has an error. :-(
There are _3_ split points present in every filename.
ArtifactId|version|classifier|type
There, now I feel better.
- Joakim
Joakim Erdfelt wrote:
> There are 4 split points present in every filename.
> ArtifactId|version|classifier|type
>
> Determining the artifactId and version is easy enough with maven 2
> default layout, as the artifactId and version are present in the full
> path to the artifact.
>
> example:
> http://repo1.maven.org/maven2/groovy/groovy-1.0-jsr/06/groovy-1.0-jsr-06.jar
>
>
> But working with maven 1 requests, this is *much* more ambiguous and
> non deterministic.
>
> Some file / layout problems found in Jira.
>
> MRM-519 [Fail to resolve artifactId for libs that contain
> versionKeyword in artifactId, like "maven-test-plugin"]
> This comes from the fact that you are likely requesting the
> maven-test-plugin from using a maven 1 (legacy) layout format from a
> repository on archiva that is configured as maven 2 (default) layout
> storage.
> This translation cannot work 100% of the time.
>
> MRM-432 [Proxy Connectors are unable to download artifacts with alpha
> numerical version numbers]
> This one is about oddball version ids such as found in
> ganymed-ssh-build210.jar, comm-3.0-u1.jar, and
> ejb-3.0-public_review.jar. These version specs are difficult to
> identify as part of the version, and not the classifier.
>
> MRM-517 [Some maven 2 requests are treated as maven 1 requests]
> This is due to the duality of request handling in the present
> /repository/ URL.
>
> Some Ideas:
>
> One idea I had last night was to rework the filename to artifact
> object for Legacy layout to be a list of potential Artifact object's,
> but this is really only relevant when working with the translation
> between an incoming request at maven 1 (legacy) to a maven 2 (default)
> resource. (this flow applies for internal repository translation, and
> also proxying of content from remote repos at different layout formats)
>
> Another idea is to split the /repository/ url into two, using the
> /repository/legacy/ or /repository/default/ identifiers to clearly
> identify what your intention is. Use this along with pom information
> on the same file (when a legacy request occurs) should clear up any
> confusion.
>
> - Joakim
>
>
> nicolas de loof wrote:
>> As Joakim noticed, my quick-fix patch breaks many testcases. It also
>> doesn't covers some valid cases, like the use of classifiers with "-"
>> tokens.
>>
>> Still looking for a working artifactId detection strategy...
>>
>> I myself sometime hardly discover the artifactId. Lets look at groovy :
>> "groovy-1.0-jsr-06"
>>
>> Is this "groovy" artifact with version "1.0-jsr-06",
>> or (as it is in repo) "groovy-1.0-jsr" version "06" ?
>> I'm not sure there is any fully deterministic way to solve this.
>>
>> Maybe the only way to solve this is to have RepositoryLayoutUtils
>> manage an "exception" list to it's default token based discovery. And
>> this would require some more UI to configure it...
>>
>> Nico.
>>
>> 2007/9/25, nicolas de loof <ni...@gmail.com>:
>>
>>> I've created http://jira.codehaus.org/browse/MRM-519 for this and
>>> attached a patch.
>>>
>>> 2007/9/25, nicolas de loof <ni...@gmail.com>:
>>>
>>>> I just installed beta-2 in replacement to my corporate repo.
>>>> I may had better tested it before :-(
>>>>
>>>> requesting using maven1 an artifact with "-" in artifactID fails :
>>>>
>>>> request for "maven/plugins/maven-test-plugin-1.8.2.jar"
>>>> in logs :
>>>> <proxied>\maven\maven\test-plugin-1.8.2\maven-test-plugin-1.8.2.jar
>>>> does not exist
>>>>
>>>> The versionUtil.versionPatterns seems to grab too much tags as
>>>> possible version.
>>>>
>>>> I've patched it locally to remove "test[_.0-9]*" as possible version
>>>> pattern. Could we enhance this artifactId detection by ensuring ALL
>>>> tokens considered as version are valid versionElements ?
>>>>
>>>> Something like this :
>>>> [- <artifactId-Element>]+ [- <versionElement>]+ [- <classifier>]?
>>>>
>>>> In such case, for "maven-test-plugin-1.8.2", as "plugin" is not a
>>>> valid versionElement, "test" and "plugin" may have been added to the
>>>> artifactId
>>>>
>>>>
>>
>>
>
>
--
- Joakim Erdfelt
joakim@erdfelt.com
Open Source Software (OSS) Developer
Problems with Legacy Layout Detection (Was: Re: critical issue with
1.0-beta-2 !!!)
Posted by 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
Re: critical issue with 1.0-beta-2 !!!
Posted by nicolas de loof <ni...@gmail.com>.
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.
> > >
> >
>
Re: critical issue with 1.0-beta-2 !!!
Posted by 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.
> >
>
Re: critical issue with 1.0-beta-2 !!!
Posted by 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.
>
Re: critical issue with 1.0-beta-2 !!!
Posted by 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.
Re: critical issue with 1.0-beta-2 !!!
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
In regards to the second idea.
It's two fold.
First part is to split the /repository/ into
/repository/${repoid}/${layout}/${resource}
This is to eliminate the guessing, the ambiguity, etc.
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.
This can be accomplished by simply replacing the extension with .pom and
fetching that content too.
- Joakim
nicolas de loof wrote:
> The idea of having a set of potential artifactIds is an interesting alternative.
>
> This might produce more network traffic on proxies, but is the only
> way to ensure the expected artifact requested by maven1 is found in a
> maven2 repo. Maybe a cache could be set to maintain Last recently
> Resolved legacy requests ? Or maybe some more meta-data can be sored
> in DB and attached to the groupId ?
>
> Having the repository URL splitted into deterministic layouts will not
> solve the Maven1-request-to-maven2-managed-repository issue. What do
> you mean about "Use this along with pom information on the same file
> should clear up any confusion" as to read the expected pom we need the
> artifactId, don't we ?
>
> About MRM-517, it looks strange that those path are resolved to legacy
> layout as they include more than 3 "/". The legacy layout only applies
> when the path contains 2 "/" (group/types/artifact.type). I don't have
> the source code here to confirm this and look further, and will
> inversitgate this one tomorrow.
>
>
> Nico.
>
> 2007/9/26, Joakim Erdfelt <jo...@erdfelt.com>:
>
>> There are 4 split points present in every filename.
>> ArtifactId|version|classifier|type
>>
>> Determining the artifactId and version is easy enough with maven 2
>> default layout, as the artifactId and version are present in the full
>> path to the artifact.
>>
>> example:
>> http://repo1.maven.org/maven2/groovy/groovy-1.0-jsr/06/groovy-1.0-jsr-06.jar
>>
>> But working with maven 1 requests, this is *much* more ambiguous and non
>> deterministic.
>>
>> Some file / layout problems found in Jira.
>>
>> MRM-519 [Fail to resolve artifactId for libs that contain versionKeyword
>> in artifactId, like "maven-test-plugin"]
>> This comes from the fact that you are likely requesting the
>> maven-test-plugin from using a maven 1 (legacy) layout format from a
>> repository on archiva that is configured as maven 2 (default) layout
>> storage.
>> This translation cannot work 100% of the time.
>>
>> MRM-432 [Proxy Connectors are unable to download artifacts with alpha
>> numerical version numbers]
>> This one is about oddball version ids such as found in
>> ganymed-ssh-build210.jar, comm-3.0-u1.jar, and
>> ejb-3.0-public_review.jar. These version specs are difficult to
>> identify as part of the version, and not the classifier.
>>
>> MRM-517 [Some maven 2 requests are treated as maven 1 requests]
>> This is due to the duality of request handling in the present
>> /repository/ URL.
>>
>> Some Ideas:
>>
>> One idea I had last night was to rework the filename to artifact object
>> for Legacy layout to be a list of potential Artifact object's, but this
>> is really only relevant when working with the translation between an
>> incoming request at maven 1 (legacy) to a maven 2 (default) resource.
>> (this flow applies for internal repository translation, and also
>> proxying of content from remote repos at different layout formats)
>>
>> Another idea is to split the /repository/ url into two, using the
>> /repository/legacy/ or /repository/default/ identifiers to clearly
>> identify what your intention is. Use this along with pom information on
>> the same file (when a legacy request occurs) should clear up any confusion.
>>
>> - Joakim
>>
Re: critical issue with 1.0-beta-2 !!!
Posted by nicolas de loof <ni...@gmail.com>.
The idea of having a set of potential artifactIds is an interesting alternative.
This might produce more network traffic on proxies, but is the only
way to ensure the expected artifact requested by maven1 is found in a
maven2 repo. Maybe a cache could be set to maintain Last recently
Resolved legacy requests ? Or maybe some more meta-data can be sored
in DB and attached to the groupId ?
Having the repository URL splitted into deterministic layouts will not
solve the Maven1-request-to-maven2-managed-repository issue. What do
you mean about "Use this along with pom information on the same file
should clear up any confusion" as to read the expected pom we need the
artifactId, don't we ?
About MRM-517, it looks strange that those path are resolved to legacy
layout as they include more than 3 "/". The legacy layout only applies
when the path contains 2 "/" (group/types/artifact.type). I don't have
the source code here to confirm this and look further, and will
inversitgate this one tomorrow.
Nico.
2007/9/26, Joakim Erdfelt <jo...@erdfelt.com>:
> There are 4 split points present in every filename.
> ArtifactId|version|classifier|type
>
> Determining the artifactId and version is easy enough with maven 2
> default layout, as the artifactId and version are present in the full
> path to the artifact.
>
> example:
> http://repo1.maven.org/maven2/groovy/groovy-1.0-jsr/06/groovy-1.0-jsr-06.jar
>
> But working with maven 1 requests, this is *much* more ambiguous and non
> deterministic.
>
> Some file / layout problems found in Jira.
>
> MRM-519 [Fail to resolve artifactId for libs that contain versionKeyword
> in artifactId, like "maven-test-plugin"]
> This comes from the fact that you are likely requesting the
> maven-test-plugin from using a maven 1 (legacy) layout format from a
> repository on archiva that is configured as maven 2 (default) layout
> storage.
> This translation cannot work 100% of the time.
>
> MRM-432 [Proxy Connectors are unable to download artifacts with alpha
> numerical version numbers]
> This one is about oddball version ids such as found in
> ganymed-ssh-build210.jar, comm-3.0-u1.jar, and
> ejb-3.0-public_review.jar. These version specs are difficult to
> identify as part of the version, and not the classifier.
>
> MRM-517 [Some maven 2 requests are treated as maven 1 requests]
> This is due to the duality of request handling in the present
> /repository/ URL.
>
> Some Ideas:
>
> One idea I had last night was to rework the filename to artifact object
> for Legacy layout to be a list of potential Artifact object's, but this
> is really only relevant when working with the translation between an
> incoming request at maven 1 (legacy) to a maven 2 (default) resource.
> (this flow applies for internal repository translation, and also
> proxying of content from remote repos at different layout formats)
>
> Another idea is to split the /repository/ url into two, using the
> /repository/legacy/ or /repository/default/ identifiers to clearly
> identify what your intention is. Use this along with pom information on
> the same file (when a legacy request occurs) should clear up any confusion.
>
> - Joakim
>
>
> nicolas de loof wrote:
> > As Joakim noticed, my quick-fix patch breaks many testcases. It also
> > doesn't covers some valid cases, like the use of classifiers with "-"
> > tokens.
> >
> > Still looking for a working artifactId detection strategy...
> >
> > I myself sometime hardly discover the artifactId. Lets look at groovy :
> > "groovy-1.0-jsr-06"
> >
> > Is this "groovy" artifact with version "1.0-jsr-06",
> > or (as it is in repo) "groovy-1.0-jsr" version "06" ?
> > I'm not sure there is any fully deterministic way to solve this.
> >
> > Maybe the only way to solve this is to have RepositoryLayoutUtils
> > manage an "exception" list to it's default token based discovery. And
> > this would require some more UI to configure it...
> >
> > Nico.
> >
> > 2007/9/25, nicolas de loof <ni...@gmail.com>:
> >
> >> I've created http://jira.codehaus.org/browse/MRM-519 for this and
> >> attached a patch.
> >>
> >> 2007/9/25, nicolas de loof <ni...@gmail.com>:
> >>
> >>> I just installed beta-2 in replacement to my corporate repo.
> >>> I may had better tested it before :-(
> >>>
> >>> requesting using maven1 an artifact with "-" in artifactID fails :
> >>>
> >>> request for "maven/plugins/maven-test-plugin-1.8.2.jar"
> >>> in logs :
> >>> <proxied>\maven\maven\test-plugin-1.8.2\maven-test-plugin-1.8.2.jar
> >>> does not exist
> >>>
> >>> The versionUtil.versionPatterns seems to grab too much tags as possible version.
> >>>
> >>> I've patched it locally to remove "test[_.0-9]*" as possible version
> >>> pattern. Could we enhance this artifactId detection by ensuring ALL
> >>> tokens considered as version are valid versionElements ?
> >>>
> >>> Something like this :
> >>> [- <artifactId-Element>]+ [- <versionElement>]+ [- <classifier>]?
> >>>
> >>> In such case, for "maven-test-plugin-1.8.2", as "plugin" is not a
> >>> valid versionElement, "test" and "plugin" may have been added to the
> >>> artifactId
> >>>
> >>>
> >
> >
>
>
> --
> - Joakim Erdfelt
> joakim@erdfelt.com
> Open Source Software (OSS) Developer
>
>
Re: critical issue with 1.0-beta-2 !!!
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
There are 4 split points present in every filename.
ArtifactId|version|classifier|type
Determining the artifactId and version is easy enough with maven 2
default layout, as the artifactId and version are present in the full
path to the artifact.
example:
http://repo1.maven.org/maven2/groovy/groovy-1.0-jsr/06/groovy-1.0-jsr-06.jar
But working with maven 1 requests, this is *much* more ambiguous and non
deterministic.
Some file / layout problems found in Jira.
MRM-519 [Fail to resolve artifactId for libs that contain versionKeyword
in artifactId, like "maven-test-plugin"]
This comes from the fact that you are likely requesting the
maven-test-plugin from using a maven 1 (legacy) layout format from a
repository on archiva that is configured as maven 2 (default) layout
storage.
This translation cannot work 100% of the time.
MRM-432 [Proxy Connectors are unable to download artifacts with alpha
numerical version numbers]
This one is about oddball version ids such as found in
ganymed-ssh-build210.jar, comm-3.0-u1.jar, and
ejb-3.0-public_review.jar. These version specs are difficult to
identify as part of the version, and not the classifier.
MRM-517 [Some maven 2 requests are treated as maven 1 requests]
This is due to the duality of request handling in the present
/repository/ URL.
Some Ideas:
One idea I had last night was to rework the filename to artifact object
for Legacy layout to be a list of potential Artifact object's, but this
is really only relevant when working with the translation between an
incoming request at maven 1 (legacy) to a maven 2 (default) resource.
(this flow applies for internal repository translation, and also
proxying of content from remote repos at different layout formats)
Another idea is to split the /repository/ url into two, using the
/repository/legacy/ or /repository/default/ identifiers to clearly
identify what your intention is. Use this along with pom information on
the same file (when a legacy request occurs) should clear up any confusion.
- Joakim
nicolas de loof wrote:
> As Joakim noticed, my quick-fix patch breaks many testcases. It also
> doesn't covers some valid cases, like the use of classifiers with "-"
> tokens.
>
> Still looking for a working artifactId detection strategy...
>
> I myself sometime hardly discover the artifactId. Lets look at groovy :
> "groovy-1.0-jsr-06"
>
> Is this "groovy" artifact with version "1.0-jsr-06",
> or (as it is in repo) "groovy-1.0-jsr" version "06" ?
> I'm not sure there is any fully deterministic way to solve this.
>
> Maybe the only way to solve this is to have RepositoryLayoutUtils
> manage an "exception" list to it's default token based discovery. And
> this would require some more UI to configure it...
>
> Nico.
>
> 2007/9/25, nicolas de loof <ni...@gmail.com>:
>
>> I've created http://jira.codehaus.org/browse/MRM-519 for this and
>> attached a patch.
>>
>> 2007/9/25, nicolas de loof <ni...@gmail.com>:
>>
>>> I just installed beta-2 in replacement to my corporate repo.
>>> I may had better tested it before :-(
>>>
>>> requesting using maven1 an artifact with "-" in artifactID fails :
>>>
>>> request for "maven/plugins/maven-test-plugin-1.8.2.jar"
>>> in logs :
>>> <proxied>\maven\maven\test-plugin-1.8.2\maven-test-plugin-1.8.2.jar
>>> does not exist
>>>
>>> The versionUtil.versionPatterns seems to grab too much tags as possible version.
>>>
>>> I've patched it locally to remove "test[_.0-9]*" as possible version
>>> pattern. Could we enhance this artifactId detection by ensuring ALL
>>> tokens considered as version are valid versionElements ?
>>>
>>> Something like this :
>>> [- <artifactId-Element>]+ [- <versionElement>]+ [- <classifier>]?
>>>
>>> In such case, for "maven-test-plugin-1.8.2", as "plugin" is not a
>>> valid versionElement, "test" and "plugin" may have been added to the
>>> artifactId
>>>
>>>
>
>
--
- Joakim Erdfelt
joakim@erdfelt.com
Open Source Software (OSS) Developer
Re: critical issue with 1.0-beta-2 !!!
Posted by nicolas de loof <ni...@gmail.com>.
As Joakim noticed, my quick-fix patch breaks many testcases. It also
doesn't covers some valid cases, like the use of classifiers with "-"
tokens.
Still looking for a working artifactId detection strategy...
I myself sometime hardly discover the artifactId. Lets look at groovy :
"groovy-1.0-jsr-06"
Is this "groovy" artifact with version "1.0-jsr-06",
or (as it is in repo) "groovy-1.0-jsr" version "06" ?
I'm not sure there is any fully deterministic way to solve this.
Maybe the only way to solve this is to have RepositoryLayoutUtils
manage an "exception" list to it's default token based discovery. And
this would require some more UI to configure it...
Nico.
2007/9/25, nicolas de loof <ni...@gmail.com>:
> I've created http://jira.codehaus.org/browse/MRM-519 for this and
> attached a patch.
>
> 2007/9/25, nicolas de loof <ni...@gmail.com>:
> > I just installed beta-2 in replacement to my corporate repo.
> > I may had better tested it before :-(
> >
> > requesting using maven1 an artifact with "-" in artifactID fails :
> >
> > request for "maven/plugins/maven-test-plugin-1.8.2.jar"
> > in logs :
> > <proxied>\maven\maven\test-plugin-1.8.2\maven-test-plugin-1.8.2.jar
> > does not exist
> >
> > The versionUtil.versionPatterns seems to grab too much tags as possible version.
> >
> > I've patched it locally to remove "test[_.0-9]*" as possible version
> > pattern. Could we enhance this artifactId detection by ensuring ALL
> > tokens considered as version are valid versionElements ?
> >
> > Something like this :
> > [- <artifactId-Element>]+ [- <versionElement>]+ [- <classifier>]?
> >
> > In such case, for "maven-test-plugin-1.8.2", as "plugin" is not a
> > valid versionElement, "test" and "plugin" may have been added to the
> > artifactId
> >
>
Re: critical issue with 1.0-beta-2 !!!
Posted by nicolas de loof <ni...@gmail.com>.
I've created http://jira.codehaus.org/browse/MRM-519 for this and
attached a patch.
2007/9/25, nicolas de loof <ni...@gmail.com>:
> I just installed beta-2 in replacement to my corporate repo.
> I may had better tested it before :-(
>
> requesting using maven1 an artifact with "-" in artifactID fails :
>
> request for "maven/plugins/maven-test-plugin-1.8.2.jar"
> in logs :
> <proxied>\maven\maven\test-plugin-1.8.2\maven-test-plugin-1.8.2.jar
> does not exist
>
> The versionUtil.versionPatterns seems to grab too much tags as possible version.
>
> I've patched it locally to remove "test[_.0-9]*" as possible version
> pattern. Could we enhance this artifactId detection by ensuring ALL
> tokens considered as version are valid versionElements ?
>
> Something like this :
> [- <artifactId-Element>]+ [- <versionElement>]+ [- <classifier>]?
>
> In such case, for "maven-test-plugin-1.8.2", as "plugin" is not a
> valid versionElement, "test" and "plugin" may have been added to the
> artifactId
>