[
https://issues.apache.org/jira/browse/IVY-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin reassigned IVY-431:
--------------------------------
Assignee: Xavier Hanin
> Global exclude
> --------------
>
> Key: IVY-431
> URL: https://issues.apache.org/jira/browse/IVY-431
> Project: Ivy
> Issue Type: New Feature
> Reporter: Xavier Hanin
> Assigned To: Xavier Hanin
>
> For the moment Ivy provides a way to exclude transitive dependencies provided
> by a dependency in the dependency declaration itself:
> {code:xml}
> <dependency name="A" rev="1.0">
> <exclude module="B"/>
> </dependency>
> {code}
> But sometimes the same transitive dependency is obtained by several direct
> dependencies, so you have to exclude it in several dependency declarations.
> So what would be nice is a way to exclude a module more globally:
> - at a module level (declared somewhere in the Ivy file)
> - at a global level (declared somewhere in ivyconf?)
> The problem I see with defining such a global exclude in ivyconf is that it
> makes the ivy file not self contained. It's already the case with
> conflict-manager defined globally in ivyconf, so I don't know if it's a big
> problem or not. May be we should at least warn about that, or inject ivyconf
> wide settings in the ivy file at deliver time.
> Proposed syntax:
> In Ivy files, add a top level exclude section (like the conflicts section)
> containing rules of modules/artifacts to exclude:
> {code:xml}
> <exclude>
> <rule module="*servlet*" matcher="glob" conf="weblib" />
> <rule org="acme" module="*test" artifact="test*" type="source" ext="jar"
> matcher="glob" />
> </exclude>
> {code}
> Note that the conf in the first rule corresponds to conf of the module in
> which I define the exclusion rule, and restricts the exclusion to this conf
> only (similar to the conf attribute on the exclude element of dependency).
> In ivyconf, either use the same syntax, or use the modules section to define
> exclusion the same way conflict manager are defined. The advantage of the
> latter is that it follows the existing syntax, but I think it's less clear,
> and doesn't allow to exclude artifacts only. If we follow the same syntax as
> in ivy files, the conf wouldn't be allowed since it has no meaning.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
