Daniel Kulp wrote:
> +1 to all of this.... (although it's <scope>test</scope>)
>
:-)
> Having an axis/axiom dependency on the "test" phase is possibly OK
> (although not ideal). Making the actual runtime depend on it is not OK.
>
We will need test dependencies on all technology implementations,
otherwise we can't test them :-)
I suppose the alternative is to make the SDO API and implementation
extensible e.g. by completely externalizing serialization.
> Just FYI, the JAXB 2.0 marshaller/unmarshaller has methods for the
> XMLStream* and XMLEvent* and such as well as those for InputSource, URL,
> InputStream, Source, etc.... I'm not sure if you care (since SDO is
> not JAXB), but I thought I'd mention it.
>
This highlights the issue I was trying to avoid. As I read this (and I
confess ignorance with JAXB) it sounds like there is *one*
(un-)marshaller which has methods on it for different XML access APIs.
This means that an implementation has to support *all* these different
APIs - the "kitchen sink" approach that bloats the runtime footprint.
I was hoping we would have an approach where the user only needed to
ensure that the APIs *they* were using needed to be present. For
example, if as a user I use StAX and SDO then I would just need a StAX
implementation and an SDO implementation but would not need to worry
about others (XMLBeans, Castor, JAXB, DOM, ...)
--
Jeremy
