Hi Brett, On 06/06/07, Brett Porter <[EMAIL PROTECTED]> wrote:
My recollection would be that some artifacts are filtered out but their transitive dependencies still needed to be taken into consideration for version calculations, so this could be the reason for this.
If an artifact is filtered out then why would it's transitive dependencies impact upon the resolved artifacts? The filtering performed by DefaultArtifactCollector.filterTrail appears to snip the branch at any filtered artifact.
I think it's probably better to approach this from the angle of the problem you are trying to solve - is there a reason you think it should behave differently to how it does at present?
This occurred when trying to add filtering to the maven-dependency-tree component. I'd like to specify a scope filter to the tree builder, which would in turn be passed to the artifact collector. I would then expect filtering to take place prior to resolution listener methods being invoked, otherwise the filter is a little bit pointless ;)
> Whilst everyone's busily replying to this, here's another > ResolutionListener question: are the omitForNearer and omitForCycle > methods intended to be invoked instead of, or after, the > includeArtifact method? the answer is "yes" :) they should be invoked instead of it for the current node if it should be omitted. But by the same token, the artifact may have been previously included and are later omitted. For a given node, it's "instead of".
That makes sense thanks. I'm just restructuring some of the maven-dependency-tree code and wanted to make sure I was testing it correctly.
Just a quick check - are you working on fixing up issues in 2.0.x or making other improvements and features like the conflict resolution?
The areas I'm working on at the moment are: - release poms, to allow reproducible builds with version ranges (MRELEASE-177, MRELEASE-240, MNG-3023 and our pending discussion) - making version ranges usable (MNG-2994, MNG-2988) - highest-wins conflict resolution (MNG-612) - dependency diagnostic tools (MDEP-94 and more features to come)
Given the "Artifact changes" thread, it appears there are a few people working on, or interested in working on, that area of the code but that we haven't really found a unified direction yet.
Is this the general refactor of artifact resolving proposed by Jason for 2.1? That does sound interesting and seems the way to go, although my focus is the above issues for 2.0.x since we cannot justify moving to 2.1 until it's stable. Cheers, Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
