We should add support for the maven-shade-plugin to create the super-JARs to avoid using multiple JARs? We could create one that includes log4j-api, core, slf4j-impl, and jcl. In fact, if we split up the modules better, we'd be able to create more distribution super-JARs for different scenarios.
On 5 April 2014 14:51, Gary Gregory <[email protected]> wrote: > Please, no. At some point, you might as well use just the class files you > need... I'd rather think about how few jars I need... at some point I'd > like to to create a log4j-all module, just like Jetty and ActiveMA have > -all modules. For us, we can't throw the kitchen sink in but we'll come up > with a sensible set... > > Gary > > > -------- Original message -------- > From: Matt Sicker > Date:04/05/2014 14:49 (GMT-05:00) > To: Log4J Developers List > Subject: Proposal to split up plugins API into its own module(s). > > In order to support LOG4J-595, technically, I think it could all be done > as part of the core package and would still work. As a matter of design, > however, I'd like to propose the following split: > > log4j-core-api: > - Contains the main interfaces used in the core module but not specified > by the api module > - Would also contain the annotations > - Optionally, we could also include some abstract classes here, too > > log4j-core: > - Contains the rest of log4j-core that wasn't removed (some classes may > need to be updated or moved around to avoid splitting packages across more > than one module). > > log4j-plugin-processor: > - Contains the PluginManager along with the annotation processor code. > > Going this route would allow 3rd party plugin writers to depend on less > code in order to implement their own plugins. It would also help our own > code by allowing more fine-grained modules if we want to go that route > eventually. > > Like I said, though, this isn't entirely necessary. I just like the idea, > but I would need buy-in from the rest of us to go forward with this idea. > I'm not sure which type of vote would be appropriate here, but I'd imagine > it would be one of the member-or-higher level votes. > > -- > Matt Sicker <[email protected]> > -- Matt Sicker <[email protected]>
