Too fine grained dependencies will be difficult for users. I like log4j-jdbc log4j-jpa log4j-jms log4j-kafka log4j-zeromq
If these share anything I'm okay to keep that in core. Sent from my iPhone > On 6 Dec 2016, at 2:54, Matt Sicker <boa...@gmail.com> wrote: > > You don't need to include "nosql" in the split modules. I'd only use "nosql" > or "sql" as common dependencies (i.e., the abstract classes). > >> On 5 December 2016 at 11:23, Gary Gregory <garydgreg...@gmail.com> wrote: >>> On Mon, Dec 5, 2016 at 9:08 AM, Mikael Ståldal <mikael.stal...@magine.com> >>> wrote: >>> I don't think we should create a new module just to save a single digit >>> number of KB in core. >> >> So from your POV, it's all about reducing dependencies? I'm just trying to >> understand what the landscape is here... >> >> Gary >> >>> >>>> On Mon, Dec 5, 2016 at 5:42 PM, Gary Gregory <garydgreg...@gmail.com> >>>> wrote: >>>>> On Mon, Dec 5, 2016 at 8:25 AM, Matt Sicker <boa...@gmail.com> wrote: >>>>> I agree with Mikael here. It would be nice to include the abstract base >>>>> classes in log4j-core if they're dependency-free, but I don't have a >>>>> strong opinion on whether to make it its own module. >>>>> >>>>> Also, yes, log4j-nosql should be split along with the other modules. >>>> >>>> Ah, right, dependencies. So: >>>> >>>> log4j-db >>>> log4j-db-nosql >>>> log4j-db-nosql-counchdb >>>> log4j-db-nosql-mongodb >>>> log4j-db-jdbc >>>> log4j-db-jpa >>>> >>>> If we really want to thin our core, that justifies having log4j-db and >>>> log4j-db-nosq. >>>> >>>> Then we are almost at the one package = one jar level. At least in this >>>> area. The one package = one jar would be one extreme way to deliver log4j >>>> but the dependencies, yikes. >>>> >>>> Gary >>>> >>>>> >>>>>> On 5 December 2016 at 03:30, Mikael Ståldal <mikael.stal...@magine.com> >>>>>> wrote: >>>>>> I would prefer the modules to be named like this to make names less >>>>>> clumsy: >>>>>> >>>>>> log4j-jdbc >>>>>> log4j-jpa >>>>>> log4j-jms >>>>>> log4j-kafka >>>>>> log4j-zeromq (better than log4j-jeromq) >>>>>> >>>>>> It seems like the proposed log4j-db module would be very small and not >>>>>> have any external dependencies? In that case I suggest we keep that >>>>>> stuff in log4j-core to avoid creating too many modules. We should only >>>>>> create new modules if they have external dependencies or are of >>>>>> considerable size. >>>>>> >>>>>> BTW, the log4j-nosql modules should probably be split up further into >>>>>> log4j-mongodb and log4j-couchdb. >>>>>> >>>>>>> On Mon, Dec 5, 2016 at 10:21 AM, Mikael Ståldal >>>>>>> <mikael.stal...@magine.com> wrote: >>>>>>> I think we should focus on splitting into modules now, and worry about >>>>>>> repos later. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Mon, Dec 5, 2016 at 6:29 AM, Gary Gregory <garydgreg...@gmail.com> >>>>>>>> wrote: >>>>>>>> Possible modules and names, with the idea that they all depend on >>>>>>>> log4j-db: >>>>>>>> >>>>>>>> log4j-db >>>>>>>> log4j-db-nosql >>>>>>>> log4j-db-jdbc >>>>>>>> log4j-db-jpa >>>>>>>> >>>>>>>> The naming hints that log4j-db is the parent of all log4j-db-* modules. >>>>>>>> >>>>>>>> We can do something similar for MOM (JMS) except that JMS, ZeroMQ and >>>>>>>> Kafka appenders do not share code but we could leave room for that. >>>>>>>> >>>>>>>> log4j-mom (not needed ATM) >>>>>>>> log4j-mom-jms >>>>>>>> log4j-mom-kafka >>>>>>>> log4j-mom-zeromq (or log4j-mom-jeromq) >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>>> On Sun, Dec 4, 2016 at 3:46 PM, Gary Gregory <garydgreg...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> Hm: NoSqlDatabaseManager extends AbstractDatabaseManager, so >>>>>>>>> log4j-nosql would depend on log4j-db unless we leave >>>>>>>>> AbstractDatabaseManager and friends in core. >>>>>>>>> >>>>>>>>> Gary >>>>>>>>> >>>>>>>>>> On Sun, Dec 4, 2016 at 1:54 PM, Matt Sicker <boa...@gmail.com> wrote: >>>>>>>>>> I wish we had a better way to gauge what plugins are the most >>>>>>>>>> commonly used so we could trim it down to that in log4j-core, but >>>>>>>>>> alas, we can really only guess. With that in mind, that layout >>>>>>>>>> sounds like it makes sense, though calling it "log4j-db" is somewhat >>>>>>>>>> confusing. I'd prefer the name had some sort of indicator that it >>>>>>>>>> wasn't a standalone module as it wouldn't have any concrete plugins >>>>>>>>>> in it. >>>>>>>>>> >>>>>>>>>> Also, would log4j-nosql need to depend on log4j-db? Could be a nice >>>>>>>>>> opportunity for refactoring if necessary as they all follow the same >>>>>>>>>> pattern. >>>>>>>>>> >>>>>>>>>>> On 4 December 2016 at 15:40, Gary Gregory <garydgreg...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> OK, I have a log4j-sql module split out locally. But it seems we >>>>>>>>>>> need instead: >>>>>>>>>>> >>>>>>>>>>> - log4j-db (commons code, depends log4j-core) >>>>>>>>>>> - log4j-jdbc (JDBC only, depends on log4j-db) >>>>>>>>>>> - log4j-jpa (JPA only, depends on log4j-db) >>>>>>>>>>> >>>>>>>>>>> I would also repackage these out of .core. >>>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> >>>>>>>>>>> Gary >>>>>>>>>>> >>>>>>>>>>>> On Sun, Dec 4, 2016 at 1:28 PM, Gary Gregory >>>>>>>>>>>> <garydgreg...@gmail.com> wrote: >>>>>>>>>>>> Note the common code in .core.db for .core.db.jdbc and >>>>>>>>>>>> .core.db.jpa. It seems just that little bit should go in its own >>>>>>>>>>>> module or stay in core. >>>>>>>>>>>> >>>>>>>>>>>> Gary >>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Dec 4, 2016 at 1:15 PM, Gary Gregory >>>>>>>>>>>>> <garydgreg...@gmail.com> wrote: >>>>>>>>>>>>> Also: package names, it does not make sense to have JDBC and JPA >>>>>>>>>>>>> code under the .core. package anymore. I would: >>>>>>>>>>>>> >>>>>>>>>>>>> Create the new modules with code not in .core. and deprecate the >>>>>>>>>>>>> equivalent in .core. >>>>>>>>>>>>> >>>>>>>>>>>>> Gary >>>>>>>>>>>>> >>>>>>>>>>>>>> On Sun, Dec 4, 2016 at 1:08 PM, Gary Gregory >>>>>>>>>>>>>> <garydgreg...@gmail.com> wrote: >>>>>>>>>>>>>> Hm... this is also an opportunity to pick more precise names: >>>>>>>>>>>>>> log4j-jdbc and log4j-jpa >>>>>>>>>>>>>> >>>>>>>>>>>>>> Gary >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sun, Dec 4, 2016 at 12:56 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> As for SQL, the JDBC one doesn't have any dependencies, so that >>>>>>>>>>>>>>> could stay in core if desired, but the JPA one does require >>>>>>>>>>>>>>> additional Java EE APIs, so that'd make sense to separate at >>>>>>>>>>>>>>> the very least. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As for the nosql ones, again, it would be nice to split those >>>>>>>>>>>>>>> up so that there aren't optional dependencies. That would >>>>>>>>>>>>>>> either mean a mongo and couch component, or it could also mean >>>>>>>>>>>>>>> an additional nosql-common component (unless the abstract >>>>>>>>>>>>>>> classes were put into log4j-core). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 4 December 2016 at 12:44, Gary Gregory >>>>>>>>>>>>>>>> <garydgreg...@gmail.com> wrote: >>>>>>>>>>>>>>>> Thoughts on splitting out SQL and MOM (JMS) into their own >>>>>>>>>>>>>>>> modules? We already have a nosql module, having a sql one >>>>>>>>>>>>>>>> makes sense. The overall idea is to make core lighter. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>> Spring Batch in Action >>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>> JUnit in Action, Second Edition >>>>>>>>> Spring Batch in Action >>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>> Home: http://garygregory.com/ >>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>> JUnit in Action, Second Edition >>>>>>>> Spring Batch in Action >>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>> Home: http://garygregory.com/ >>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> 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. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> 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> >>>> >>>> >>>> >>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>> Java Persistence with Hibernate, Second Edition >>>> JUnit in Action, Second Edition >>>> Spring Batch in Action >>>> Blog: http://garygregory.wordpress.com >>>> Home: http://garygregory.com/ >>>> Tweet! http://twitter.com/GaryGregory >>> >>> >>> >>> -- >>> >>> >>> 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. >> >> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second Edition >> JUnit in Action, Second Edition >> Spring Batch in Action >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory > > > > -- > Matt Sicker <boa...@gmail.com>
