I think we need to strike some balance here. Another think to keep in mind is to make it easy to get started as a new developer/bug fixer/hacker. The more complicated we make the build, the more modules, the harder it will become to play in the sandbox. IOW, the fewer jars and modulers, the better IMO.
Gary On Sat, Apr 5, 2014 at 4:05 PM, Matt Sicker <[email protected]> wrote: > 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]> > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
