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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > >>>> wrote: > >>>>> > >>>>> On Apr 24, 2017 2:38 AM, "Mikael Ståldal" <[email protected] > > > >>>> 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 <[email protected]> > 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 <[email protected]> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> [image: MagineTV] > >>>>> > >>>>> *Mikael Ståldal* > >>>>> Senior software developer > >>>>> > >>>>> *Magine TV* > >>>>> [email protected] > >>>>> 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 <[email protected]> > >>> > > > > > -- Matt Sicker <[email protected]>
