[
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