[orbit-dev] Question and Suggestion for a way out of Xerces dilemma?

[David M Williams <david_williams@xxxxxxxxxx>]

You may recall xerces, as distributed
at Apache, consists of two jars, the implementation and an xml-apis.jar.

In the past, we (WTP) have always used
these as one bundle. 

When moved to Orbit, I split the two
jars into two bundles. 

The API one, though, has turned out
to be 'controversial' if not down right incorrect. Because I named it "org.w3c.dom.

But, it also could be broken into three
bundles, org.w3.com, javax.xml, and org.sax.xml. 

So, here it is "RC2 time"
and I have not had time to sort through all the issues involved in doing
the correct split. In fact, just found a new 
set of issues to sort though in the
OSGi spec, where they have some specific recommendations on "migrating"
JAXP parsers 
to OSGi!

So, my fear is that if we leave "org.w3c.dom"
and anyone depends on it (with 'require bundle') for something from "javax.xml",
then they will be broken 
in future releases if/when the interfaces
are correctly split up, in bundles with proper names. 

This seems risky to me, and as far as
I know no one has a large dependancy on this org.w3c.dom bundle in orbit,
except for a few cases which could 
easily be fixed by replacing it with
a dependancy on xerces (I'm fairly sure). 

So, do others see this as a serious
issue? 

I'd suggest we take the current org.w3c.dom
bundle and make it a fragment of the xerces implementation. Xerces would
still re-export all the interfaces, 
as it does now. Then anyone who needs
anything from xerces (or those interfaces) would have to 'require bundle'
xerces, instead of w3c.dom. 

Then we'll consider/try again next release.


If you all in Orbit agree this is the
right approach, then I will approach projects via cross-project list. 

Sound ok? 

I guess the alternative is just to warn
everyone that if they use org.w3c.dom they will automatically be broken
and have to change that next release ... 
but, that would have to be a "coordinated
change" so everyone knows when to make the switch. (And, no matter
how much you warn people, they 
will feel it's an API break later on).


Suggestions welcome.