XSLT Dependencies by OSGI Links
I am researching OSGI to determine its viability for updating an existing project. The project currently consists of modules (which are basically just directories) that contain XSL Transforms. Transforms contain dependencies on transformations from other modules in the form of xsl: import and xsl: include statements. The reason I am considering OSGI is that as the number of modules increases, it becomes more difficult to track dependencies and test modules effectively.
Is it possible to use an OSGI framework to declare the XML / XSLT resources contained in a package and reference those resources in XSL Transforms import statements in a separate package.
source to share
Yes it works as Lukasz pointed out, you need to write a simple URIResolver based on the expander model. An interesting approach is to use the Provide-Capability and Require-Capability headers to model dependencies. This will allow you to handle dependencies with good diagnostics, it allows you to run multiple versions side by side, and it will work with OBR, a resolver that can find missing parts. See http://www.osgi.org/blog/2012/03/requirements-and-capabilities.html
And this will be the first time I'll see the use of the fact that XSLT is XML ... you could write a simple stylesheet that generated Require-Capability headers! :-)
source to share
Your question seems very interesting. Personally, I am working on a system that has two packages. One package implements the XSLT Processor implementation (we are using Saxon), and the second one implements several XSLT files (which use the statement xsl:import
). And this works in the OSGi environment (actually, Fuse ESB), but we need to implement the interface javax.xml.transform.URIResolver
and pass it to the converter.
I assume you will need to use a similar approach. Hope this helps.
source to share
I would just use Maven to manage dependencies if you were you - it's easier to set up your dependencies and it handles transitive dependencies very well. Use OSGi if you need to modify XSL modules at runtime. In both cases, you need to implement the URIResolver
one mentioned in the other answer.
source to share