[ 
https://issues.apache.org/jira/browse/IVY-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465236
 ] 

Xavier Hanin commented on IVY-393:
----------------------------------

All these tasks already have a transitive attribute, as documented in the post 
resolve task page: http://incubator.apache.org/ivy/doc/use/postresolvetask.html

The difference is that full dependency resolution is not done when you set 
transitive to false, similarly to non transitive configurations. So I think 
your request could be reviewed as "add a way to configure the way non 
transitive post resolve tasks are handled", by adding a way to ask for full 
resolution (as you want) or not (as it is currently implemented). 

Suggestions for how to configure that are welcome.

> Add "transtive" attribute to <cachepath>, <cachefileset> and <retrieve>
> -----------------------------------------------------------------------
>
>                 Key: IVY-393
>                 URL: https://issues.apache.org/jira/browse/IVY-393
>             Project: Ivy
>          Issue Type: New Feature
>          Components: Ant, Core
>    Affects Versions: 1.4.1
>         Environment: all
>            Reporter: John Williams
>            Priority: Minor
>
> It would be useful to have a "transitive" option similar, but not identical, 
> to the "transitive" attribute of configurations.  Why not identical?  If 
> there are two configurations that are identical except that one is transitive 
> and the other is not, the two configurations can choose different revisions 
> for some modules due to conflict resolution.  (For instance, if my module 
> depends on modA-1.0 and modB-1.0, and modB-1.0 depends on modA-1.1, the 
> transitive config will use modA-1.1 and the other config will use modA-1.0.)  
> The option for <cachepath>, etc. should exclude indirect dependencies without 
> affecting which revision is used.
> My rationale for this feature is that I would really like to have two 
> classpaths--one for compile time and the other for run time--that are 
> identical except that the compile-time classpath would have only direct 
> dependencies.  I like having only direct dependencies at compile time because 
> it ensures that all the direct dependencies are declared to Ivy, but the 
> versions of all modules *must* be the same as the run-time classpath in order 
> to avoid causing a lot of confusion.  (A lesser reason for preferring a 
> classpath with only direct dependencies is that javac is much faster with a 
> small classpath.)

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

        

Reply via email to