Oh I agree on the ease of use. Just look at super-modular projects like Arquillian and try to figure out where the fudge anything is! I think that the original API/core split Ralph did for log4j 2 was a great idea, though. However, it seems like log4j-core itself could be split into an API and implementation module at the very least. That way, people can write third party plugins by only depending on log4j-api and log4j-core-api. Then again, that's not too different than using a provided dependency on log4j-core, is it?
On 5 April 2014 15:57, Gary Gregory <[email protected]> wrote: > 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 > -- Matt Sicker <[email protected]>
