Community
Participate
Working Groups
The split of org.eclipse.wst.xml.xpath2.wtptypes from org.eclipse.wst.xml.xpath2.processor didn't make it into M6. It is in CVS and builds with Hudson+Tycho, but hasn't been released to the map files yet. I would like to crate the bundle 'org.eclipse.wst.xml.xpath2.wtptypes' (and an associated test bundle) and add this as a dependency in org.eclipse.wst.xml.xpath.core. Marking this as an exception as I guess as it is a bundle change, awaiting PMC approval and M6 I-build promotion to Indigo site on March 15th.
Review or approval, I don't know, I just don't want to cause problems.
I'm fine with this. Thanks for keeping us informed. But ... can you summarize what "wtptypes" is? Why splitting? How might adopters be effected? I assume all is still contained in one feature, and this split is for those where users use the xpath2 processor as a 'standalone' jar? Thanks.
(In reply to comment #2) > I'm fine with this. Thanks for keeping us informed. But ... can you summarize > what "wtptypes" is? Why splitting? How might adopters be effected? I assume all > is still contained in one feature, and this split is for those where users use > the xpath2 processor as a 'standalone' jar? > > Thanks. Yes, the split is exactly to reduce coupling. The "wtptypes" code is an implementation on the XPath2 "TypeModel"-interface against the SSE+XSD type model. It is also useful in the XSL plugin, and for other potential adopters (XQuery development tools might find it useful, too) "wtptypes" was the best name I could come up with to signify that it was not just XSD model specific, since it depends on SSE/XML too. Suggestions for a better name are welcome! If the introduction of an extra bundle is an issue (I guess there's a memory and start-up overhead), we could move the code into org.eclipse.wst.xml.xpath.core bundle, which is the non-UI part of the XPath view - it does contain some extra stuff and dependencies, but it is very small. How big is the extra overhead of adding one additional bundle, runtime-wise?
> > How big is the extra overhead of adding one additional bundle, runtime-wise? It is not much as long as there is no "startup" code, and as long as the bundle is 'jarred'. If the code is in its own distinct package (namespace) then probably best to have/leave in distinct bundle.
This one is fixed in M7, resolving.