Thanks for the help Dan. I think I'm getting a solution--I just need to
explicitly state the version of cxf-api and cxf-runtime-core that I need in
the <DependencyManagement/> section, rather than rely on Maven's default
dependency resolution. Another option that seems to work is using
dependency exclusion filters; i.e. placing exclusions on the two cxf
artifacts wrongfully trying to bring in nonexistent 1.0 jars. Because other
cxf artifacts are correctly bringing in 2.0.3 versions of the above, those
two artifacts end up using the correct 2.0.3 versions. Still testing so
far. BTW, a few more questions:
dkulp wrote:
>
> Hmm... OK.... Not sure what to say then although it's probably the same
> issue as ServiceMix had on the Mac.
>
> There is a bug in Maven where system properties can overwrite and affect
> anything that uses "${project.version}" and/or "${pom.version}" like we
> do.
Questions:
1.) Do you know if the Maven team is aware of this problem--is it in their
JIRA?
2.) Any reason why this might not be occurring with CXF 2.0.2? Or did the
ServiceMix
problem also occur with CXF 2.0.2?
dkulp wrote:
>
> The issue is that some XML parsers or processor (like the one
> built into the OSX jvm) has a tendency to set a "version" system
> property which messes that up. Thus, any plugin that does XML
> processing at all can cause major issues. Unfortunately, our wsdl2java
> plugin does XML processing.
>
3.) I'm probably exposing my Maven noviceness here, but can CXF be changed
to stop using ${project.version} and ${pom.version} internally then to avoid
this error? If I understand you correctly, as long as CXF avoids these
properties, the problem goes away, correct?
Thanks,
Glen
--
View this message in context:
http://www.nabble.com/Maven-dependency-problem-upgrading-from-CXF-2.0.2-to-2.0.3-tp14921161p14929951.html
Sent from the cxf-user mailing list archive at Nabble.com.
