Details
-
Proposal
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
Description
As described in dev@karaf.apache.org list I'd like to think about mechanism similar to one implemented with KARAF-5376, but concerning bundles themselves.
When features service checks (to resolve) and installs a bundle, it could transform it according to some rules.
Currently I have idea about fixing Manifest headers, in order for example to widen javax.servlet API import range. That's common case with every major JavaEE/ServletAPI release that it breaks current applications even if it's fully compatible.
Without pasting everything I posted to mailing list, here's example configuration within etc/org.apache.karaf.features.xml:
<bundleProcessing> <bundle location="mvn:org.eclipse.jetty*/*"> <add header="Processed-By" value="Karaf Bundle Processor" /> <clause header="Import-Package" name="javax.servlet" value='javax.servlet;version="[3.1.0,5)"' /> <clause header="Import-Package" name="javax.servlet.annotation" value='javax.servlet.annotation;version="[3.1.0,5)"' /> <clause header="Import-Package" name="javax.servlet.descriptor" value='javax.servlet.descriptor;version="[3.1.0,5)"' /> <clause header="Import-Package" name="javax.servlet.http" value='javax.servlet.http;version="[3.1.0,5)"' /> </bundle> </bundleProcessing>
Processed bundles go (by default) to ${karaf.data}/repository-bpr and then are resolved using default repositories feature of pax-url-aether.
Attachments
Issue Links
- is related to
-
KARAF-5376 Processor mechanism for feature definitions (a.k.a. "better overrides")
- Resolved