[
http://issues.ops4j.org/browse/PAXLOGGING-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925#action_13925
]
Niclas Hedhman commented on PAXLOGGING-96:
------------------------------------------
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.
> Plz dont bundle the sl4fj impl w/ pax-logging-api it causes classpath
> problems etc
> ----------------------------------------------------------------------------------
>
> Key: PAXLOGGING-96
> URL: http://issues.ops4j.org/browse/PAXLOGGING-96
> Project: Pax Logging
> Issue Type: Improvement
> Reporter: Miroslav Pokorny
>
> 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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.ops4j.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
