Well, I've tried a few different methods using the maven-bundle-plugin, but nothing seems to be working. The only promising looking goals (wrap and bundleall) are both deprecated. I think we might be able to get away with using the assembly plugin or something to copy over the necessary files from log4j-core to build the various bundles.
On 31 March 2014 20:21, Ralph Goers <[email protected]> wrote: > 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]> > > -- Matt Sicker <[email protected]>
