They don't seem to work for one. They only declare dependency information and don't actually import anything. The API bundle looks fine as it's generated directly from log4j-api, but the log4j-core bundles are empty (except for a manifest file).
On 31 March 2014 18:37, Ralph Goers <[email protected]> wrote: > What is wrong with the approach we have been using under the osgi module - > each Maven module is some subset of core. > > Ralph > > On Mar 31, 2014, at 1:59 PM, Matt Sicker <[email protected]> wrote: > > Alright, the basic problem is that each bundle corresponds logically to a > Maven module. Since we have only one log4j-core module with optional > dependencies, that apparently goes completely against how this would > normally be done. Realistically, the better idea would be to split up > log4j-core into logical modules based on optional dependencies (thus making > them required) and then use the maven-shade-plugin to assemble a log4j-core > artifact to avoid having to use multiple JARs in typical environments (or > when you aren't using Maven/Gradle/etc.). It's how most other projects are > being organized nowadays, and that's probably also due to OSGi. > > If we continue with the monolithic log4j-core with optional dependencies, > then creating OSGi versions would require a custom Ant build most likely. > In order to get application servers to upgrade log4j, they'll probably > desire OSGi bundles as all the major app servers use OSGi presently. We > don't need to use anything from OSGi other than using Maven modules > logically. If this is undesired, I don't really know how to provide bundles > other than through a custom build process which would defeat the purpose of > using Maven. > > -- > Matt Sicker <[email protected]> > > > -- Matt Sicker <[email protected]>
