Eventually I went the way of adding it as an Embed-Dependency. It's
probably yet-another-xerces so I'm not sure it's optimal, but at least
it's cleaner and won't tamper with other bundles.
I also removed it from the owl module (I was wrong thinking it was
embedded by the owlapi).
The same was done with the mysql-connector-java in reengineer/db.
Alessandro
On 10/10/11 12:59 PM, Alessandro Adamou wrote:
Hi,
in reengineer/xml we are using xercesImpl-2.7.1.
The Xerces JAR used to be in the bundle resources and included in the
bundle classpath, but we didn't really like that solution.
So, as per STANBOL-301 we removed it altogether (also the
reengineer/xerces bundle, which was no longer built anyway), and had
the owl bundle export its version 2.7.1 which comes along with the OWL
API.
However this can cause troubles in our Sling launchers. The
com.hp.hpl.jena.tdb bundle uses Xerces version 2.9.1 and exports the
org.apache.xerces.util package (the rest of xerces is not exported),
without declaring version 2.9.1 in the manifest. So I have experienced
conflicts on that package.
So far, the solution was to have stanbol.owl export all the Xerces
packages BUT org.apache.xerces.util . Obviously this is a sub-optimal
workaround so to speak.
I need to find the best way to ensure reengineer/xml uses the right
Xerces version (2.7.1) without tampering with the rest of the OSGi
platform.
Should I have it as an Embed-Dependency or something like that? Is
there an elegant solution that could save us the pain of having many
embedded xercesImpl-2.7.1 all around Stanbol?
Cheers
--
M.Sc. Alessandro Adamou
Alma Mater Studiorum - Università di Bologna
Department of Computer Science
Mura Anteo Zamboni 7, 40127 Bologna - Italy
Semantic Technology Laboratory (STLab)
Institute for Cognitive Science and Technology (ISTC)
National Research Council (CNR)
Via Nomentana 56, 00161 Rome - Italy
"As for the charges against me, I am unconcerned. I am beyond their timid, lying
morality, and so I am beyond caring."
(Col. Walter E. Kurtz)
