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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
