I guess that log4-core will become:

   - log4j-core (will depend on log4j-spi)
   - log4j-spi
   - log4j-csv
   - log4j-xml (XmlLayout)
   - log4j-json (JsonLayout)
   - log4j-yaml (YamlLayout)
   - log4j-kafka
   - log4j-smtp
   - log4j-jms
   - log4j-jdbc (or can this be kept in log4j-core?)
   - log4j-jpa
   - log4j-zeromq
   - log4j-server (already done, not yet released)
   - log4j-tools (command line tools)


Then we should also split log4j-nosql:

   - log4j-cassandra
   - log4j-couchdb
   - log4j-mongodb
   - log4j-lucene (new, under development)



On Mon, Apr 24, 2017 at 7:43 PM, Remko Popma <remko.po...@gmail.com> wrote:

> How many new modules are we talking about, concretely?
>
> Matt mentioned the StackOverflow questions about transitive dependencies
> etc, but I imagine splitting log4j-core into 5 or more new modules will
> also cause confusion... It won't be trivial for users to figure out which
> of the many modules they do or don't need. The coarse granularity of the
> current modules is a good thing for users.
>
> What problem are we trying to solve? And how can we solve it with the least
> disruption to our users?
>
> Would it be an idea, for example, to provide separate jars for the separate
> modules, but in addition create a combined jar (log4j-core-all) that
> contains all the classes in log4j-core as well as the classes in the new
> modules we split out from core?
>
>
> On Tue, Apr 25, 2017 at 2:00 AM, Matt Sicker <boa...@gmail.com> wrote:
>
> > I agree with Ralph here. I'm sure we'll figure out rather quickly which
> > modules are easy to put into rarely updated repositories.
> >
> > On 24 April 2017 at 11:39, Ralph Goers <ralph.go...@dslextreme.com>
> wrote:
> >
> > > I would prefer a hybrid approach.  First things should be moved to
> > > separate modules. Then, if they don’t seem to be modified frequently
> they
> > > can be moved to a separate repo. For example, I think it would be OK
> for
> > > the Flume Appender to be in a separate repo. It hasn’t changed in
> quite a
> > > while and I can’t remember the last time it was modified due to changes
> > in
> > > Log4j it has and while continue to change with changes made in Flume
> > > releases.  I imagine we have quite a few components that are similar.
> > >
> > > Ralph
> > >
> > > > On Apr 24, 2017, at 8:39 AM, Gary Gregory <garydgreg...@gmail.com>
> > > wrote:
> > > >
> > > > On Apr 24, 2017 2:38 AM, "Mikael Ståldal" <mikael.stal...@magine.com
> >
> > > wrote:
> > > >
> > > > I fully agree with Matt's both proposals.
> > > >
> > > > I'm skeptic to creating more repositories (than we already have)
> > though.
> > > I
> > > > think that we should start by splitting out modules from log4j-core
> and
> > > > keep those modules in the main repository with synchronized
> versioning
> > > and
> > > > releases, at least for the 2.9 release. We can always move those
> > modules
> > > to
> > > > other repositories later if we want to.
> > > >
> > > >
> > > > I do not like more repos either. Since we have already gone down the
> > more
> > > > modules road, I say we keep going.
> > > >
> > > > Gary
> > > >
> > > >
> > > > It is a lot of administrative work to create a new repository (as we
> > have
> > > > seen for log4j-scala), I don't want us to do all that work over and
> > over
> > > > again unless really necessary.
> > > >
> > > > We have a JIRA ticket for this:
> > > > https://issues.apache.org/jira/browse/LOG4J2-1650
> > > >
> > > > I have already started by breaking out log4j-server:
> > > > https://issues.apache.org/jira/browse/LOG4J2-1851
> > > >
> > > > I think the next step is to break out plugins (layouts and appenders)
> > > with
> > > > optional 3rd party dependencies into their own modules.
> > > >
> > > >
> > > > On Sun, Apr 23, 2017 at 7:45 PM, Matt Sicker <boa...@gmail.com>
> wrote:
> > > >
> > > >> I think I brought this topic up like 3 years ago when I was working
> on
> > > >> initial OSGi support, but now that we have 3 more years worth of
> code
> > > >> additions and optional features, I think this might be a more
> > > appropriate
> > > >> time to discuss it again in light of experience.
> > > >>
> > > >> Building log4j-core itself already takes a long time, and many
> plugins
> > > >> aren't updated very often at all. In the past, requiring users to
> > simply
> > > >> add log4j-core plus any transitive dependencies to use optional
> > features
> > > >> seemed to work well enough, but I still think that's a confusing
> > > >> distribution mechanism as demonstrated by the numerous bug reports
> and
> > > >> Stack Overflow posts regarding missing transitive dependencies for
> > > various
> > > >> features. I spent some time experimenting with Log4j Boot a little
> > while
> > > >> ago to help alleviate this problem, but this may be unnecessary if
> we
> > > can
> > > >> agree to modularize log4j-core itself.
> > > >>
> > > >> I have two different proposals, both of which can be used at the
> same
> > > > time.
> > > >>
> > > >> 1. Split out everything from log4j-core that requires 3rd party
> > > >> dependencies (except for AsyncLogger, though perhaps we could
> consider
> > > >> shading and renaming those classes like some other low level
> libraries
> > > do
> > > >> with JCTools). Ideally, I'd like to see each module have required
> > > >> dependencies instead of optional ones, so that if, for instance, I
> > > include
> > > >> a "log4j-config-yaml" dependency, I know that Log4j will support
> YAML
> > > >> configuration without having to specify the individual Jackson
> > > >> dependencies.
> > > >>
> > > >> 2. Split out from log4j-core a sort of log4j-spi module which
> defines
> > > >> interfaces, abstract classes, and annotations for plugins that would
> > be
> > > >> promoted to the same level of backwards compatibility guarantees as
> > > >> log4j-api. This would aid in cementing what we really wish to
> maintain
> > > >> compatibility with in the backend while allowing other modules to
> have
> > > > less
> > > >> strict guarantees.
> > > >>
> > > >> With proposal #1, I'd think that we could more easily start moving
> > > modules
> > > >> into separate repositories and release trains. Without #2, though,
> > this
> > > >> makes version support more annoying to handle, but that's what we'll
> > > face
> > > >> regardless as we separate more repositories. If we go this route,
> then
> > > >> there will be no need for a Log4j Boot subproject.
> > > >>
> > > >> What do you all think?
> > > >>
> > > >> --
> > > >> Matt Sicker <boa...@gmail.com>
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > [image: MagineTV]
> > > >
> > > > *Mikael Ståldal*
> > > > Senior software developer
> > > >
> > > > *Magine TV*
> > > > mikael.stal...@magine.com
> > > > Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com
> > > >
> > > > Privileged and/or Confidential Information may be contained in this
> > > > message. If you are not the addressee indicated in this message
> > > > (or responsible for delivery of the message to such a person), you
> may
> > > not
> > > > copy or deliver this message to anyone. In such case,
> > > > you should destroy this message and kindly notify the sender by reply
> > > > email.
> > >
> > >
> > >
> >
> >
> > --
> > Matt Sicker <boa...@gmail.com>
> >
>



-- 
[image: MagineTV]

*Mikael Ståldal*
Senior software developer

*Magine TV*
mikael.stal...@magine.com
Grev Turegatan 3  | 114 46 Stockholm, Sweden  |   www.magine.com

Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.

Reply via email to