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

[David M Williams <david_williams@xxxxxxxxxx>]

Technically no, but we don't currently
export packages with version numbers, so, not sure the packages provided
by this xerces bundle would get picked up over any other providers. 
That's part of the same issues ... what
exactly should the version numbers of some packages be. 

173587
2007-02-08 nor P3 david_williams@xxxxxxxxxx david_williams@xxxxxxxxxx NEW
bundles --- Improve Xerces constraints

Christian Damus <cdamus@xxxxxxxxxx>
Sent by: orbit-dev-bounces@xxxxxxxxxxx

05/29/2007 09:20 AM

Please respond to
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>

To	Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>
cc
Subject	Re: [orbit-dev] Question and Suggestion for a way out of        Xerces        dilemma?

Hi, David, 

Will this be an issue for clients that use Import-Package instead of Require-Bundle
(which I think is what we Orbiters recommend strongly that clients do with
Orbit bundles)? 

Christian

---

Christian W. Damus
Component Lead, Eclipse OCL
and EMF-QTV
IBM
Rational Software

David M Williams <david_williams@xxxxxxxxxx>
Sent by: orbit-dev-bounces@xxxxxxxxxxx

05/29/07 01:33 AM

Please respond to
Orbit Developer discussion <orbit-dev@xxxxxxxxxxx>

To	orbit-dev@xxxxxxxxxxx
cc
Subject	[orbit-dev] Question and Suggestion for a way out of Xerces        dilemma?

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. 
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev
_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev