I had a great idea inspired by Mark from Tomcat (forget his full name) in regards to splitting up core: we can set up a parallel repository that uses svn:external to organise the various packages into separate modules. Then separate pom.xml files can be written for these sub-modules. This might be a better route to go.
In Tomcat, they keep all their source code in one tree. However, their Ant build scripts build several JARs from that tree by pulling in various sub-directories. This is actually a big reason why they couldn't easily move to Maven (amongst other reasons I bet). It was suggested to make a parallel repository like I mentioned above. Also, amusingly enough, Lucas, I've had quite a similar discussion here before. The main thing here is that nobody seems to think that core is large enough to be split. It's a different way of thinking about development when you move to OSGi. On 12 April 2014 09:39, Ralph Goers <rgo...@apache.org> wrote: > Also, if you drop Log4j into a web container currently it will > automatically initialize in a Servlet 3 container. I’ve always been a bit > uncomfortable with that and it was originally in its own jar, but others > preferred it the way it currently is. > > Ralph > > On Apr 12, 2014, at 7:20 AM, Ralph Goers <rgo...@apache.org> wrote: > > Jackson is used to parse JSON configuration files and JMX is currently > defaulted to be always enabled. > > Ralph > > On Apr 12, 2014, at 3:24 AM, Łukasz Dywicki <l...@code-house.org> wrote: > > Ralph, > For these who wants a "big” log4j you might provide aggregate JAR just > like astyanax does. I think it’s much easier going this direction than > other way around. Fine grained dependencies are proof of good library > design. In slf4j epoch developers do not depend on any log4j code except > test scope where mostly used is FileAppender. During deployment time it > doesn’t make big difference too because only one place which would be > affected is assembly. I can also imagine that some people could still love > spring log4j stuff and will not need direct log4j support for it. > > I can understand that disruptor might be mandatory to provide asynchronous > behaviour but why JMX and Jackson could not be separated? > > Best regards, > Łukasz Dywicki > -- > l...@code-house.org > Twitter: ldywicki > Blog: http://dywicki.pl > Code-House - http://code-house.org > > Wiadomość napisana przez Ralph Goers <ralph.go...@dslextreme.com> w dniu > 12 kwi 2014, o godz. 06:26: > > There is a balance that needs to be struck here. We don’t want to add > support for OSGi at the cost of forcing non-OSGi users to have to include a > bunch of Log4j dependencies. That said, I suggest the other day that we > might want to split some things that a majority of our users will rarely > use into other modules, possible in a companion project to the Log4j kernel. > > We actually have a few dependencies, such as Jackson, the disruptor, and > JMX that are optional but really can’t be separated from the core. > > That said, an analysis of what could be separated is warranted. > > Ralph > > On Apr 11, 2014, at 3:40 PM, Łukasz Dywicki <l...@code-house.org> wrote: > > Hey all, > Apachecon has been ended so I am following the promise I did - I’ve taken > a look on the log4j build to check what’s going on with OSGi stuff. > Currently OSGi bundles are split from main log4j-core which I think leads > to maintanance trouble also number of dependencies of log4j-core seems to > be very high. If we could split the log4j-core into smaller modules > (mongodb, jms, jmx, web) then there will be no need to keep log4j-osgi and > it’s submodules. > According to maven guides [1] "Optional dependencies are used when it's > not really possible (for whatever reason) to split a project up into > sub-modules”, I think it will also make library design much more clear and > will avoid making unecessary inner code deps. Seems that big, aggregate > modules, are always grow to size which require major work to split them to > make both: maintanance and community involvement possible. > > [1] > https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html > > Cheers, > Łukasz Dywicki > -- > l...@code-house.org > Twitter: ldywicki > Blog: http://dywicki.pl > Code-House - http://code-house.org > > > > > -- Matt Sicker <boa...@gmail.com>
