Dependency resolution for org.apache.cxf:cxf-api:2.6.10 seems wrong

The dependency tree for cxf-api seems wrong. Maven and Gradle disagree about the version of jaxb-impl required

Gradle:

|
+--- org.apache.cxf:cxf-rt-core:2.6.10
|
|
+--- com.sun.xml.bind:jaxb-impl:2.1.13
|
|
\--- org.apache.ws.xmlschema:xmlschema-core:2.0.3

Maven:

|
+- org.apache.cxf:cxf-rt-core:jar:2.6.10:compile
|
|
+- com.sun.xml.bind:jaxb-impl:jar:2.2.5.1:compile
|
|
\- org.apache.ws.xmlschema:xmlschema-core:jar:2.0.3:compile

I’m not sure how Gradle resolves its dependencies, but the pom.xml in Maven central references cxf-parent for depencencyManagement which contains the following lines:

<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>${cxf.jaxb.impl.version}</version>

And also:

<cxf.jaxb21.version>2.1</cxf.jaxb21.version>
<cxf.jaxb21.impl.version>2.1.13</cxf.jaxb21.impl.version>
<cxf.jaxb21.xjc.version>2.1.13</cxf.jaxb21.xjc.version>
<cxf.jaxb22.version>2.2.5</cxf.jaxb22.version>
<cxf.jaxb22.impl.version>2.2.5.1</cxf.jaxb22.impl.version>
<cxf.jaxb22.xjc.version>2.2.5.1</cxf.jaxb22.xjc.version>
<!--
 by default, we use jaxb 2.1, but java5 profile will override to 2.2
 -->
<cxf.jaxb.version>${cxf.jaxb21.version}</cxf.jaxb.version>
<cxf.jaxb.impl.version>${cxf.jaxb21.impl.version}</cxf.jaxb.impl.version>

There are profiles are enabled with the 1.5 and 1.7 JDK that should use later versions of jaxb-impl. Not sure if this is a problem in the way Gradle resolves dependencies, but it seems that it should I believe the correct version of jaxb-impl is 2.2.5.1 as Maven reports when I’m compiling with 1.7.

I think gradle has taken the stance that profiles in a published artifact are a bad idea and are not supported. Recently, a fix went in to gradle 1.12 to support the default profile ie:

<activeByDefault>true</activeByDefault>

See http://issues.gradle.org//browse/GRADLE-1997

Related discussion http://forums.gradle.org/gradle/topics/gradle_does_not_appear_to_read_properties_defined_in_maven_profiles

Even the Maven community takes that stance. It’s impossible for us to support all possible forms of “dynamic” published POMs, but we are trying to address the basic/common cases.