Hello (sorry for writing to two mailing lists, but I think it's important).
I've just found nasty problem. After having lots of fun with pax-logging-service and pax-logging-logback I wanted to clean up pax-logging-log4j2. But I found that original, already available pax-logging-log4j2 bundle actually has Export-Package header (pax-logging-service and pax-logging-logback don't export anything). The strange thing was that all bundles have: Export-Package: \ !* The difference is that pax-logging-log4j2 additionally has <https://github.com/ops4j/org.ops4j.pax.logging/blob/b8c9137/pax-logging-log4j2/osgi.bnd#L5> : Private-Package: \ ... META-INF; -split-package:=merge-first, \ ... So it ... took the META-INF/MANIFEST.MF from org.apache.logging.log4j:log4j-core. It wouldn't be a problem if pax-logging-log4j2 exported something - even single package. Here's why <https://github.com/bndtools/bnd/blob/4.2.0.REL/biz.aQute.bndlib/src/aQute/bnd/osgi/Analyzer.java#L1063-L1065> (aQute.lib.osgi.Analyzer#calcManifest()): // Copy old values into new manifest, when they // exist in the old one, but not in the new one merge(manifest, dot.getManifest()); pax-logging-log4j2 bundle didn't have any Export-Package (as intended), so it just inherited it from org.apache.logging.log4j:log4j-core (definitely *not* as intended...). This is related to https://ops4j1.jira.com/browse/PAXLOGGING-240 and the discussion here[1]. To be honest, the only thing I think is sensible here is to stop exporting anything from pax-logging-log4j2... Extensions should be done via fragments or pax-logging-api's org.ops4j.pax.logging.spi interfaces (like PaxAppender). WDYT? regards Grzegorz Grzybek === [1]: https://groups.google.com/forum/#!msg/ops4j/yjqOzvrKRkc/t5BXmfyoBgAJ
