I would propose that we do the same thing I suggested with the Stream support - 
move it to a branch until it is ready.  Ideally the branch should only have 
what is needed for OSGi and not all of Log4j.  Also, I have no problems making 
changes such as moving classes around in support of OSGi, just not adding more 
jars.

I am wondering if it wouldn’t be a good idea to have two log4j projects - one 
for the kernel, which would include all of the “fundamental” appenders, 
layouts, filters, etc, and a second for things like the Flume Appender, NoSQL 
Appenders, etc.  

I’m worried that we are starting to throw too much into the main project, but I 
don’t want to stop development that helps people integrate with other things.

Ralph

On Apr 9, 2014, at 8:06 AM, Paul Benedict <[email protected]> wrote:

> The great thing about open source is that someone can republish the code as 
> smaller artifacts, if they choose. I don't think log4j should pick up this 
> slack unless someone's experiment proves extremely beneficial. We can always 
> backport someone's good ideas once proven. :-) I will take a wait-and-see 
> approach and leave it to the module experts to prove their idea.
> 
> 
> On Wed, Apr 9, 2014 at 10:02 AM, Gary Gregory <[email protected]> wrote:
> The benefit of not having all of these OSGi modules is that it makes Log4J 
> "lighter" and more approachable.
> 
> Gary
> 
> 
> On Wed, Apr 9, 2014 at 10:47 AM, Paul Benedict <[email protected]> wrote:
> Resist splitting things up unless there's a clear distinguishing benefit. 
> 
> 
> On Wed, Apr 9, 2014 at 8:03 AM, Gary Gregory <[email protected]> wrote:
> Hi all,
> 
> Today some people want to slice and dice log4j 2 into ever finer OSGI 
> bundles. Tomorrow, people will want to do the same with whatever Oracle comes 
> up with in project Jigsaw. Some people don't care for OSGi support. 
> 
> This is bound to be a big mess. 
> 
> Therefore I'd like to propose to split off OSGi and later Jigsaw into a 
> separate project(s). This way people who care about OSGi can do all that they 
> need without polluting the main log4j project with dozens of Maven modules. 
> 
> Thoughts?
> Gary
> 
> 
> 
> -- 
> Cheers,
> Paul
> 
> 
> 
> -- 
> E-Mail: [email protected] | [email protected] 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> -- 
> Cheers,
> Paul

Reply via email to