If you browse around the Java 9 javadocs, you'll see that they split things up by module there as well. With that in mind, hopefully it's not too complicated to support. What I really want to see is inter-module links (both Java modules and Maven modules that is) work properly.
On 25 April 2017 at 11:49, Ralph Goers <ralph.go...@dslextreme.com> wrote: > Ouch. This is where it gets messy. Currently, the javadoc is built > independently for each module. I’m not sure how to aggregate them all > together but I’m sure Java 9 must be doing that with all the modules they > are supporting. > > Ralph > > > On Apr 25, 2017, at 7:03 AM, Mikael Ståldal <mikael.stal...@magine.com> > wrote: > > > > When adding new modules to the main repo, does each module need its own > > site directory? > > > > On Tue, Apr 25, 2017 at 4:02 PM, Mikael Ståldal < > mikael.stal...@magine.com> > > wrote: > > > >> Yes, they should stay in the main repo, at least for the time being. > >> > >> On Tue, Apr 25, 2017 at 3:56 PM, Gary Gregory <garydgreg...@gmail.com> > >> wrote: > >> > >>> And all of that should stay in the same repo IMO. > >>> > >>> Gary > >>> > >>> On Apr 25, 2017 2:51 AM, "Mikael Ståldal" <mikael.stal...@magine.com> > >>> wrote: > >>> > >>>> 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. > >>>> > >>> > >> > >> > >> > >> -- > >> [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. > >> > > > > > > > > -- > > [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>
