Re: Repo selection [Was: JIRA MNG-2098]

[Brett Porter <br...@apache.org>]

It's not exactly a side effect, but I see why its a bug. The collector
can't select the repository as it doesn't know where it will be present.

The current logic is based on the use of snapshots - it considered that
releases would only be in one so the first found is used, whereas for
snapshots all must be checked and the newest used. I believe it works
for the latter.

It seems to be falling down only for version ranges, correct? I had
thought these should also operate as a transformation but that doesn't
sit with the whole resolution technique.

The actual version selection should be assigning a single repository to
it where the correct version was found.

This area of the code needs a lot more tests, in the order of what the
collector itself has. I suspect doing so will probably yield a lot of
clues for a better design also.

- Brett

Garrett Conaty wrote:
> Thought it was appropriate to bring my comments out of the jira issue
> for discussion on the list.
> 
> Basically, I want to work on a more elegant fix for this issue but am
> requesting some community guidance.  Specifically for the issue:
> 
> 
> 1) Should the DefaultArtifactResolver really use
> artifact.getRepository() exclusively if it's not null?  Perhaps the
> Artifact really ought to contain a list of repositories that are
> acceptable (from the transformation phase) from which to try.  This may
> be a good enhancment.
> 
> but the more pressing issue is
> 2) Shouldn't the DefaultArtifactCollector actually do the repository
> selection, not have it be a side effect of getting the metadata.
> 
> Thanks,
> Garrett
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: Repo selection [Was: JIRA MNG-2098]

[Casey Butterworth <ca...@suncorp.com.au>]

I can confirm that this is still happening in 2.0.6 and 2.0.7. However, the
issue is more substantial than originally thought, i.e. not only happening
for ranges but also for LATEST version transformation.

In our scenario, we are trying to resolve
org.codehaus.mojo:jaxb2-maven-plugin and have not specified a version (i.e.
LATEST). The following 2 repositories are specified for this project and
both have the artifact available (central has the releases,
codehaus.snapshot the snapshots).

central: http://repo1.maven.org/maven2/
codehaus.snapshot: http://snapshots.repository.codehaus.org/

In this scenario, DefaultRepositoryMetadataManager.mergeMetadata (line 167)
is correctly updating the MetaData to include the versions from both the
central and snapshot repositories. However, the repositories are processed
in the order (1) central (2) codehaus.snapshot, and therefore the
codehaus.snapshot repository is being set as the selected repository (line
169) as the last repo iterated over.

Afterwards, LatestArtifactTransformation.constructVersion() is retrieving
the LATEST version (1.2) which is not available in the pre-selected repo
(codehaus.snapshot), and the plugin's pom is not retrieved (resulting in a
"Artifact not found - using stub model: Unable to locate resource in
repository"). In this instance, this causes a ClassDefNotFound as the jaxb2
plugin's pom specifies dependencies.

We are able to work around the problem by (a) specifying a version for the
plugin (1.2) or (b) specifying the dependencies in the plugin definition,
however, it took a while to get to this stage.

I am reasonably sure that the fix suggested by Garrett would fix the
problem.

Let me know if this is not clear enough.

Cheers 


brettporter wrote:
> 
> The current logic is based on the use of snapshots - it considered that
> releases would only be in one so the first found is used, whereas for
> snapshots all must be checked and the newest used. I believe it works
> for the latter. 
> 
> It seems to be falling down only for version ranges, correct? I had
> thought these should also operate as a transformation but that doesn't
> sit with the whole resolution technique.
> 

-- 
View this message in context: http://www.nabble.com/Repo-selection--Was%3A-JIRA-MNG-2098--tf1164364s177.html#a12011447
Sent from the Maven Developers mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org