It turns out there was a very subtle, and evil, issue sitting the Ivy/maven configuration, and it
related to dependency mapping.
It turns out there was a very subtle, and evil, issue sitting the Ivy/maven configuration, and it
related to dependency mapping. A mapping of foo->bar(*) means that the local configuration
foo depends on the remote configuration bar, if it exists, or *ALL CONFIGURATIONS* if bar
does not exist. Since the default Ivy configuration mapping was using the random master
configuration, which AFAICT is NEVER specified, just an assumed default, this would cause leaks
between maven + ivy projects.
i.e. if a maven POM depends on a module denoted by an ivy.xml file, then you'd wind up accidentally
bleeding ALL the ivy module's configurations into the maven module's configurations.
This fix works around the issue, by assuming that if there is no master configuration, than the
maven default of compile is intended. As sbt forces generated ivy.xml files to abide by
maven conventions, this works in all of our test cases. The only scenario where it wouldn't work
is those who have custom ivy.xml files *and* have pom.xml files which rely on those custom ivy.xml files,
a very unlikely situation where the workaround is: "define a master configuration".
Also see: http://ant.apache.org/ivy/history/2.3.0/ivyfile/dependency.html
and: http://svn.apache.org/repos/asf/ant/ivy/core/tags/2.3.0/src/java/org/apache/ivy/plugins/parser/m2/PomModuleDescriptorBuilder.java
It turns out there was a very subtle, and evil, issue sitting the Ivy/maven configuration, and it related to dependency mapping. A mapping of
foo->bar(*)means that the local configurationfoodepends on the remote configurationbar, if it exists, or *ALL CONFIGURATIONS* ifbardoes not exist. Since the default Ivy configuration mapping was using the randommasterconfiguration, which AFAICT is NEVER specified, just an assumed default, this would cause leaks between maven + ivy projects.i.e. if a maven POM depends on a module denoted by an ivy.xml file, then you'd wind up accidentally bleeding ALL the ivy module's configurations into the maven module's configurations.
This fix works around the issue, by assuming that if there is no
masterconfiguration, than the maven default ofcompileis intended. As sbt forces generatedivy.xmlfiles to abide by maven conventions, this works in all of our test cases. The only scenario where it wouldn't work is those who have custom ivy.xml files *and* have pom.xml files which rely on those custom ivy.xml files, a very unlikely situation where the workaround is: "define a master configuration".Also see: http://ant.apache.org/ivy/history/2.3.0/ivyfile/dependency.html and: http://svn.apache.org/repos/asf/ant/ivy/core/tags/2.3.0/src/java/org/apache/ivy/plugins/parser/m2/PomModuleDescriptorBuilder.java