They are probably just built wrong Ralph
> On Mar 31, 2014, at 5:54 PM, Matt Sicker <[email protected]> wrote: > > 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]>
