You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Felix Simmendinger (JIRA)" <ji...@apache.org> on 2009/04/14 09:56:14 UTC
[jira] Created: (IVY-1063) add accessors to conflictManagers in
org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor to allow
better maven pom generation
add accessors to conflictManagers in org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor to allow better maven pom generation
---------------------------------------------------------------------------------------------------------------------------------------
Key: IVY-1063
URL: https://issues.apache.org/jira/browse/IVY-1063
Project: Ivy
Issue Type: Wish
Components: Maven Compatibility
Affects Versions: 2.0
Reporter: Felix Simmendinger
Fix For: 2.1.0
One of the major drawbacks in ant-ivy development is that maven is the defacto standard so we need to produce best fitted pom files.
To generate poms where local excludes are transferred is easy when you stick to conventions. To map overrides and conflicts to explicit dependencies is the most straight forward solution to transfer ivys superior dependency management to maven boiler plate. For overrides its quite easy but for conflicts we need to access the conflictManagers ModuleRules. Its private and there is no accessor in the interface.
Another Point is how to deal with global excludes. It would be nice if canExclude(ModuleId id) would also work transitively or if there would be a transitive method, then it would be possible to work with global excludes for our own modules and local exlcludes for third party.
We are building 50+ modules with overall 1.000K+ lines of code and we have to produce maven poms as best as possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-1063) add accessors to conflictManagers in
org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor to allow
better maven pom generation
Posted by "Felix Simmendinger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12704539#action_12704539 ]
Felix Simmendinger commented on IVY-1063:
-----------------------------------------
The Problem is, that a conflict element corresponds to an explicit
dependency in maven because the dependencyManagement feature is no good
alternative here. Anyway i need an extra dependency and not an exclusion.
To get the conflict elements explicitly i need that accessor.
greets Felix
> add accessors to conflictManagers in org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor to allow better maven pom generation
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: IVY-1063
> URL: https://issues.apache.org/jira/browse/IVY-1063
> Project: Ivy
> Issue Type: Wish
> Components: Maven Compatibility
> Affects Versions: 2.0
> Reporter: Felix Simmendinger
> Fix For: 2.1.0
>
>
> One of the major drawbacks in ant-ivy development is that maven is the defacto standard so we need to produce best fitted pom files.
> To generate poms where local excludes are transferred is easy when you stick to conventions. To map overrides and conflicts to explicit dependencies is the most straight forward solution to transfer ivys superior dependency management to maven boiler plate. For overrides its quite easy but for conflicts we need to access the conflictManagers ModuleRules. Its private and there is no accessor in the interface.
> Another Point is how to deal with global excludes. It would be nice if canExclude(ModuleId id) would also work transitively or if there would be a transitive method, then it would be possible to work with global excludes for our own modules and local exlcludes for third party.
> We are building 50+ modules with overall 1.000K+ lines of code and we have to produce maven poms as best as possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1063) add accessors to conflictManagers in
org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor to allow
better maven pom generation
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maarten Coene updated IVY-1063:
-------------------------------
Fix Version/s: (was: 2.1.0)
> add accessors to conflictManagers in org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor to allow better maven pom generation
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: IVY-1063
> URL: https://issues.apache.org/jira/browse/IVY-1063
> Project: Ivy
> Issue Type: Wish
> Components: Maven Compatibility
> Affects Versions: 2.0
> Reporter: Felix Simmendinger
>
> One of the major drawbacks in ant-ivy development is that maven is the defacto standard so we need to produce best fitted pom files.
> To generate poms where local excludes are transferred is easy when you stick to conventions. To map overrides and conflicts to explicit dependencies is the most straight forward solution to transfer ivys superior dependency management to maven boiler plate. For overrides its quite easy but for conflicts we need to access the conflictManagers ModuleRules. Its private and there is no accessor in the interface.
> Another Point is how to deal with global excludes. It would be nice if canExclude(ModuleId id) would also work transitively or if there would be a transitive method, then it would be possible to work with global excludes for our own modules and local exlcludes for third party.
> We are building 50+ modules with overall 1.000K+ lines of code and we have to produce maven poms as best as possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-1063) add accessors to conflictManagers in
org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor to allow
better maven pom generation
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699405#action_12699405 ]
Maarten Coene commented on IVY-1063:
------------------------------------
Could you give more details why you need access to the conflictManagers ModuleRules and why the existing getConflictManager(ModuleId moduleId) isn't good enough?
> add accessors to conflictManagers in org.apache.ivy.core.module.descriptor.DefaultModuleDescriptor to allow better maven pom generation
> ---------------------------------------------------------------------------------------------------------------------------------------
>
> Key: IVY-1063
> URL: https://issues.apache.org/jira/browse/IVY-1063
> Project: Ivy
> Issue Type: Wish
> Components: Maven Compatibility
> Affects Versions: 2.0
> Reporter: Felix Simmendinger
> Fix For: 2.1.0
>
>
> One of the major drawbacks in ant-ivy development is that maven is the defacto standard so we need to produce best fitted pom files.
> To generate poms where local excludes are transferred is easy when you stick to conventions. To map overrides and conflicts to explicit dependencies is the most straight forward solution to transfer ivys superior dependency management to maven boiler plate. For overrides its quite easy but for conflicts we need to access the conflictManagers ModuleRules. Its private and there is no accessor in the interface.
> Another Point is how to deal with global excludes. It would be nice if canExclude(ModuleId id) would also work transitively or if there would be a transitive method, then it would be possible to work with global excludes for our own modules and local exlcludes for third party.
> We are building 50+ modules with overall 1.000K+ lines of code and we have to produce maven poms as best as possible.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.