A couple of observations:
- This is an issue not isolated to CXF, it is a common issue with any
API. Take the Java SDK API, for that matter -- over the years I've
seen this same exact discussion take place about the Java API, and the
many portions of it that some didn't put to use in their applications,
and why they had to incur the full size of the runtime libraries in
their application. And upgrade any packages on Linux lately? Same
thing there....
- While this may indeed point to documentation issues in CXF, it also
likely points a little to available time and resource. I'm not sure
what it takes to decouple all of these libraries from one another, but
I'm guessing doing so may require a little extra work . It also may be
related to the easiest and quickest way to bring CXF to the masses
(but then again, I don't know, maybe not).
- That said, the point of the thread is a good one. Perhaps the
biggest challenge is determining the common configuration use cases.
Perhaps if the developers with a longer tenure with CXF could list the
common configuration scenarios they see, a Maven dependency
configuration could be accomplished which minimized unneeded excess.
Brad
On Dec 1, 2008, at 7:24 AM, Benson Margulies wrote:
Unless you need RPC encoding, which Axis preserves and CXF hasn't got.
On Mon, Dec 1, 2008 at 9:23 AM, Steve Cohen <[EMAIL PROTECTED]>
wrote:
Christian Schneider wrote:
...
BTW. If you have CXF in your project it does not make a lot of
sense to
also use Axis. I think you should decide on time for your project
which
webservice stack to use and stick with it.
I agree with this, basically, but it's a question of time. I have
a CXF
client going for one WS and an Axis client going for the other,
both with
vendor-provided help/sample classes. I haven't yet tried to put them
together into a single application yet. If you have war stories
that can
dissuade me from trying, I'd certainly be willing to listen and
thankful for
it.
Steve
