Stephan - many many thanks! Fragment trick works like a charm. Looks like I was not thinking enough in OSGi concepts (or maybe I was trying to be too clever? :)
regards Grzegorz Grzybek wt., 19 mar 2019 o 12:34 Grzegorz Grzybek <gr.grzy...@gmail.com> napisał(a): > Thanks Stephan for valuable comment. > > I agree that it'd be possible to simply remove all Import-Package headers > from all bundles. But that's not done by default. You have to be very > explicit when creating custom distribution. I'm not doing this change > upstream and also I created this > https://issues.apache.org/jira/browse/KARAF-6200 as "proposal" with minor > priority. > > Using fragment bundle sounds like great alternative - was it the same case > with org.apache.aries.blueprint.core.compatibility-1.0.0.jar ? > > regards > Grzegorz Grzybek > > wt., 19 mar 2019 o 11:30 Siano, Stephan <stephan.si...@sap.com> > napisał(a): > >> Hi Jean-Baptiste, >> >> What Grzegorz is proposing looks to me like some magic behind-the-scenes >> automatic wrap for all kind of installed bundles. >> >> I am not sure if this is really such a good idea. If it works, it can >> make things work that do not work without some significant effort like >> manually wrapping all bundles that reference the servlet API. If there are >> issues, you will have a situation, which is extremely hard to analyze with >> having bundles wiring to other bundles they are not supposed to be wiring >> according to their manifest. >> >> Even if that works with servlet API 4.0 for some reason, once that >> mechanism is there, it will likely be used for other packages, and once you >> have defined changes to several packages which cause the auto-wrap of >> dozens of bundles, I really think that it will be very difficult to >> understand the wiring afterwards. >> >> Therefore IMHO the least ugly workaround for this issue would be to >> create a fragment bundle for the servlet-api bundle that exports the >> packages with some lower version number (e.g. 3.2) that is only installed >> if it's really necessary. Over time the developers of the bundles >> referencing the servlet API hopefully asses whether their bundle also works >> with the servlet 4.0 API and adapt their import ranges accordingly (so the >> fragment can go away eventually). >> >> Best regards >> Stephan >> >> -----Original Message----- >> From: Jean-Baptiste Onofré <j...@nanthrax.net> >> Sent: Dienstag, 19. März 2019 10:24 >> To: dev@karaf.apache.org >> Subject: Re: Idea - how to override bundle headers without wrap: >> >> Hi Grzegorz >> >> I think what you are proposing is at different level than wrap. >> >> wrap is more for single jar (and works "outside" of Karaf) whereas your >> proposal is at feature level. >> >> It makes sense but we have to keep it simple and clear (in term of >> documentation). I think we should improve the feature processing >> documentation: in which case should I use it, and how to use it. >> >> But overall +1 to me. >> >> Regards >> JB >> >> On 19/03/2019 08:26, Grzegorz Grzybek wrote: >> > Hello >> > >> > I was thinking about one scenario. In my custom distro, I'm using >> pax-web >> > 7.3.3 (tech preview >> > <https://groups.google.com/d/msg/ops4j/JP5L63Qh4u8/nPG1LN4HAAAJ>) which >> > uses Undertow 2, Tomcat 9 and Servlet API 4. >> > >> > The "problem" is that maven-bundle-plugin, by default (and correctly) >> > generates import ranges according to pom dependencies. So if pom has >> > javax.servlet-api-3.1.0 dep, generated Import-Package header will have >> > (correctly) "[3.1,4.0)" range which is the most natural range according >> to >> > semantic versioning. >> > >> > The problem is that with some deps (and servlet-api used in >> > "@org.osgi.annotation.versioning.ConsumerType" mode is such dependency) >> > you're safe to use newer version of the API. >> > >> > There were different approaches to this problem, see for example: >> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=385806 where bundles >> either >> > export packages in many versions or export lower version than one >> matching >> > directly JavaEE specification. For example, >> > geronimo-servlet_3.0_spec-1.0.jar exports javax.servlet package with >> > version 2.6 and 3.0. >> > >> > What I did (locally) is a little enhancement to new >> override&blacklisting >> > mechanism configured in etc/org.apache.karaf.features.xml. I added this >> > section for example: >> > >> > <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> >> > >> > My goal was to be able to install for example "camel-websocket" feature >> > which uses jetty which (at version 9.4) requires servlet API 3.1. >> > >> > FeaturesProcessor (the one that currently can override URIs of bundles >> or >> > entire feature, blacklist features, bundle and repository URIs, has >> > (locally in my branch) ability to transform a bundle when matching some >> > criteria. >> > >> > In the above example, I can override all jetty bundles, so each >> *individual >> > clause* (unlike with wrap: where you work at header level) can be >> changed. >> > I can add full headers, remove headers, modify headers or modify >> individual >> > clauses. >> > >> > For example, to install jetty-util bundle, I had to wrap: it with: >> > >> > >> wrap:mvn:org.eclipse.jetty/jetty-util/9.4.12.v20180830$overwrite=merge&Import-Package=javax.imageio,javax.naming,javax.naming.ldap,javax.net.ssl,javax.security.auth.x500,javax.xml.parsers,org.slf4j.*;resolution:=optional;version="[1.7.25,2)",javax.servlet.*;version="[3.1,5)" >> > >> > remembering to preserve existing Import-Package clauses. >> > >> > With XML configuration I can focus only on fixing javax.servlet.* import >> > clauses. >> > >> > The transformed (repackaging + manifest change) bundles are stored in >> (by >> > default) ${karaf.data}/repository-bpr (bpr = bundle processing) >> directory, >> > which is also explicitly prepended to >> > org.ops4j.pax.url.mvn.defaultRepositories option used by maven resolver >> > used by features service. >> > >> > Fitting into existing features processor mechanism, this change is >> actually >> > not that big. I see nice potential in it, but I'd very like to get your >> > opinion on it - maybe additional ideas? Or problems with current idea? >> > >> > best regards >> > Grzegorz Grzybek >> > >> >> -- >> Jean-Baptiste Onofré >> jbono...@apache.org >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> >
