[ http://jira.codehaus.org/browse/MNG-1542?page=comments#action_51703 ] 

Tomislav Bodor commented on MNG-1542:
-------------------------------------

The problem manifests itself whenever you have a dependency trail in which not 
all dependencies are of the same type. However, I am struggling to find a 
non-war example since there are not that many types that are in use... But 
there is nothing in the code that specifically checks for wars, so the correct 
behaviour for wars is a coincidence. And it's only correct for fat wars (I'll 
come to that in a minute).

I still think the prolem is real, though, so I'll try to explain a bit better 
what I was trying to do. WAR dependencies as such are indeed not transitive, 
except in one case: when you want to build a slim war (that *doesn't* include 
its dependencies) and then you want to include all dependencies at the ear 
level. Filtering dependencies by type would allow pulling in all dependencies 
of type war and insert corresponding <module><web> entries in the 
application.xml. Similarly, all jar dependencies translate to <module><java> 
entries.

Also, not quite applicable at the moment as you cannot yet handle attached 
artefacts, but another example would be when you have an EJB client jar that 
has some dependencies (of type jar). As far as I understand, EJB client jars 
are of type 'ejb-client' in maven, not jar, so again you have a heterogeneous 
trail and none of those dependencies will be included.

I would expect the type filter to work on the final transitive closure of all 
dependencies and give me a subset that are of the specified type. Instead, it 
operates on dependency trails and has a side effect: not only does it apply to 
the dependency at the end of a trail (the one currently being considered), but 
it also (as a side effect) eliminates dependencies with heterogeneous trails. 
This feels wrong. But perhaps not... What was the original intention of 
supporting the type filter?

Thanks for looking at this.

> type attribute of artifact:dependencies doesn't work for indirect dependencies
> ------------------------------------------------------------------------------
>
>          Key: MNG-1542
>          URL: http://jira.codehaus.org/browse/MNG-1542
>      Project: Maven 2
>         Type: Sub-task
>   Components: maven-artifact-ant
>     Versions: 2.0
>     Reporter: Tomislav Bodor
>     Assignee: Brett Porter

>
>
> It appears that the type filter doesn't work properly with indirect 
> dependencies. It doesn't look like an issue with the TypeArtifactFilter 
> itself, but somewhere deeper. However, it's related to this feature, so here 
> it is...
> The problem manifests with transitive dependencies that are of different 
> type, e.g. a war artefact depends on a jar library. Whatever the type in that 
> case (jar or war), the dependency list returned by artifact:dependencies is 
> empty.
> I've traced through it and here is some more information:
> DefaultArtifactCollector applies the filter using ResolutionNode.filterTrail. 
> This iterates over the (dependency) node trail and applies the specified 
> filter to each dependency in turn. If all dependencies are of the same type 
> and the type matches the one specified in the filter, no problems. However, 
> I've got a dependency that is a war archive and that in turn has some jar 
> dependencies. If type is set to jar, filter fails when testing the first 
> dependency in the trail - the war in this case and never gets to the jar. The 
> result is that whatever the value of the type attribute, the dependency list 
> always ends up empty for trails that contain dependencies of different types.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to