jbossws-cxf-client has dependency on org.apache.ws.security:wss4j Version is defined in jboss-eap-6.2.0.Beta1-maven-repository/org/jboss/ws/cxf/jbossws-cxf/4.2.1.Final-redhat-1/jbossws-cxf-4.2.1.Final-redhat-1.pom <wss4j.version>1.6.11-redhat-1</wss4j.version> Maven repo contains version 1.6.11.redhat-1 Please fix jbossws-cxf-4.2.1.Final-redhat-XXX.pom This is regression because customer were able to use jbossws-cxf-client without any problem.
The POMs for jbossws-cxf need to keep upstream versions. The BOM is there for the user if they need productized transitive dependency versions. Rostislav, are you able to resolve the necessary dependencies using the BOM? Lin, please rebuild jbossws-cxf without modifications to upstream dependency versions for ER4.
The version changes in jbossws-cxf POM was done for bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=985894 Rebuild it: https://brewweb.devel.redhat.com/buildinfo?buildID=296916 by keeping upstream version definitions in POMs of jbossws-cxf.
Pull Request: https://github.com/jbossas/jboss-eap/pull/468
Please do NOT merge it, it breaks backward compatibility from customer point of view. jbossws-cxf-client must have redhat-XY dependencies. It's widely used on client side and customers are using it since EAP 6.0.0 GA. http://download.devel.redhat.com/brewroot/packages/org.jboss.ws.cxf-jbossws-cxf/4.2.1.Final_redhat_2/1/maven/org/jboss/ws/cxf/jbossws-cxf/4.2.1.Final-redhat-2/jbossws-cxf-4.2.1.Final-redhat-2.pom contains upstream versions.
For EAP 6.2 it will be documented that to have supported transitive dependencies the user will need to add the BOM config. IMO, this is not a problem from the user perspective. There are two possible scenarios: 1) When the user upgrades to the 6.2 version of jbossws-cxf-client, they will get upstream transitive dependencies, and their build should work as normal. Unless you can show that this breaks the user's build/app, this does not break backwards compatibility. 2) They want to use supported transitive dependencies, so they use the supported artifacts BOM. This option is a more reliable method for ensuring that transitive dependencies are correct, than what we used for previous EAP releases. The alternative (which we did for 6.1.1) is to manually update and rebuild jbossws-cxf with each ER, and this is not a good solution for long term maintenance.
Conclusion from triage meeting -- we will go with 4.2.1.Final-redhat-2 for ER4 / Beta candidate. We will need conclusion for GA.
Patch has been re-applied.
EAP 6.2.0 ER5 dependency-tree-4.2.1.Final-redhat-3 | +- org.apache.ws.security:wss4j:jar:1.6.11:compile | | \- org.opensaml:opensaml:jar:2.5.1-1:compile | | \- org.opensaml:openws:jar:1.4.2-1:compile | | \- org.opensaml:xmltooling:jar:1.3.2-1:compile | | \- joda-time:joda-time:jar:1.6.2:compile dependency-tree-4.2.1.Final-redhat-3-using-BOM. | +- org.apache.ws.security:wss4j:jar:1.6.11.redhat-1:compile (version managed from 1.6.11) | | \- org.opensaml:opensaml:jar:2.5.3.redhat-2:compile (version managed from 2.5.1-1) | | +- org.opensaml:openws:jar:1.4.4.redhat-2:compile (version managed from 1.4.4) | | | \- org.opensaml:xmltooling:jar:1.3.4.redhat-1:compile (version managed from 1.3.4) | | +- joda-time:joda-time:jar:1.6.2-redhat-4:compile | | \- xalan:serializer:jar:2.7.1-redhat-3:runtime (version managed from 2.7.1) Artifacts are available ... but still I don't like the fact that BOM must be used + and the tree differs from upstream one - e.g. xalan:serializer is not present in dep tree for upstream client. New BZ will come soon.
FYI: docs update is tracked in BZ 1016027. Paul, please provide details for Russell.
Thanks for the Release Note draft Paul. Doc Text has been reformatted for inclusion in the 6.2 Release Notes document.