It'd probably be confusing to make a log4j-core-all that only works with
Java 7 and 8, too, so it'd have to be doable somehow. I wonder how
shaded/shadowed applications are supposed to work in Java 9?
On 24 April 2017 at 14:12, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> Yeah, I have no idea how you would build the module-info.class file.
> module-info.java is compiled by the compiler and it performs checks to make
> sure the things being exported are really there. So you would need to have
> a maven module that unpacks all the classes and then compiles the
> module-info.java and then creates the uber jar for that to work.
>
> Ralph
>
> > On Apr 24, 2017, at 11:36 AM, Matt Sicker <boa...@gmail.com> wrote:
> >
> > It doesn't sound like there's a proper way to export a Java 9 module from
> > two separate JARs, though I'm not clear on the details. If we package up
> > the modules into a sort of log4j-core-all artifact, that'd be an assembly
> > detail for distribution.
> >
> > On 24 April 2017 at 13:19, Remko Popma <remko.po...@gmail.com> wrote:
> >
> >> I must be missing something, I don't see the problem. Users wouldn't
> have
> >> both the combined jar and the single-module jars on the classpath
> together,
> >> so there should not be an issue...
> >>
> >> For example, assume our current log4j-core jar is split up into
> >> * log4j-core-slim
> >> * log4j-core-appender-db
> >> * log4j-core-appender-mom
> >> * log4j-core-appender-net
> >>
> >> That is 4 jars where we used to have 1.
> >>
> >> Now, the combined jar ("log4j-core-all", for example) would have all
> >> classes of the above 4 jars.
> >>
> >> Users can then use log4j-core-all + log4j-api similar to how they
> >> currently do, no?
> >>
> >> Are you worried about users combining log4j-core-all with
> >> log4j-core-appender-db?
> >>
> >> Remko
> >>
> >> (Shameless plug) Every main() method deserves http://picocli.info
> >>
> >>> On Apr 25, 2017, at 2:55, Ralph Goers <ralph.go...@dslextreme.com>
> >> wrote:
> >>>
> >>> Guess what? If I am understanding Stephen correctly uber jars are not
> >> going to work as you can’t have multiple modules that export the same
> >> package.
> >>>
> >>> Ralph
> >>>
> >>>> On Apr 24, 2017, at 10:43 AM, 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>
> >>>>>
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Matt Sicker <boa...@gmail.com>
>
>
>
--
Matt Sicker <boa...@gmail.com>
