Details
-
Type:
Improvement
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: None
-
Fix Version/s: None
-
Component/s: None
-
Labels:None
Description
Firstly i love pax for its simplicity but its wrong imho to bundle an implementation w/ the api.jar because it is now problematic or a headache to override the impl. It also makes it difficult to mix regular java and pax tests simply because a class referring to a pax api now also pulls in the pax-logging bundled slf4j which means more headaches when there are two different incompatible slf4js. My hope would be that the two are separated. Im guessing w/ pax-logging 1.6.0 this problem is probably gone but if the two were separated then this problem should probably not repeat.
Activity
Once upon a time we had the exact opposite 
Each support API was a separate bundle and voices was raised to cut down the number of bundles. See PAXLOGGING-8.
In general;
Don't reference Pax Logging ever.
Don't deploy other API's jars in OSGi, ever. Reference each as 'provided' in the scope of Maven.
Only deploy Pax Logging in OSGi.
That should in a vast majority of cases solve these kind of problems.
Each support API was a separate bundle and voices was raised to cut down the number of bundles. See
Moving the slf4j implementation to pax-logging-impl is not really possible as the only interface between pax-logging-api and pax-logging-impl is the pax-logger so that the service can be made dynamic while still allowing clients to run. Not sure how to solve your problem cleanly.