Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 9CB58200BCF for ; Mon, 5 Dec 2016 18:08:36 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 9B3CD160B18; Mon, 5 Dec 2016 17:08:36 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 9E40E160B09 for ; Mon, 5 Dec 2016 18:08:34 +0100 (CET) Received: (qmail 58533 invoked by uid 500); 5 Dec 2016 17:08:33 -0000 Mailing-List: contact log4j-dev-help@logging.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Log4J Developers List" Reply-To: "Log4J Developers List" Delivered-To: mailing list log4j-dev@logging.apache.org Received: (qmail 58523 invoked by uid 99); 5 Dec 2016 17:08:33 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Dec 2016 17:08:33 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 323DE1803A7 for ; Mon, 5 Dec 2016 17:08:33 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.229 X-Spam-Level: ** X-Spam-Status: No, score=2.229 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, KAM_LOTSOFHASH=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=magine-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id r78pfoLAfsPt for ; Mon, 5 Dec 2016 17:08:27 +0000 (UTC) Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com [209.85.220.178]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id AA3C35F23D for ; Mon, 5 Dec 2016 17:08:26 +0000 (UTC) Received: by mail-qk0-f178.google.com with SMTP id n21so352742325qka.3 for ; Mon, 05 Dec 2016 09:08:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=magine-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=agZvLylMphh5CyK8e6KIBp1Czumc0DTUJB8wICEzvWI=; b=WEe5d8Ppq4iIPoAiQ9qkQHN/5DFH5G5JiXuDfWZE+IBTkKoCWqOenvzAJsv/pBo1NQ Eo9yKqEPjlon6bPZUVh0FaZ9hIftjidkxj7u5umdpGkiNN9Pnoi5J8y5svfFWQ+sdngB b4a2ynOa6JEat2SkBhe1q7jknZiBLJldO+PvAjc1lHFqnK95mUWXfGTdfk2sRE6xyCQv 0EQeCDIFmpTxXtGJvVUP6jfmcf+xQr7wn/JkV15K4+upyXiH1TlNA3w3KCkDCt3OL9AD XwYS5lXRZJClLMm6FiZqsn2/Z6MZRXGogOiLTdCC9aGjD3Tlcz2J4yLsXahZPARhUCEA qJ7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=agZvLylMphh5CyK8e6KIBp1Czumc0DTUJB8wICEzvWI=; b=KCIY+S1Wht+IxevYWrZUUYC41wSTSfY2EASbLDisZItdIoVw4AQNACYOAMfoDW0W2R N3Sf+DAPNjiG1uRDiZDTuKoeUBYFwSRuLiNaBSY7TWs7NzHYT0JmsseymYs//XOgzuK7 UyQE5JMsOTX7tG7CGPiYdh5CdbsCOfgcmYLYINDm8wSx3xR8N71MzuMPMNXG0nlaKUT3 LVbJywuuzI4gdhDdePtqPeqeEopqwa+ObWbX7vUr67aQBUTdG5Aw1McTJcdZSjF97fVa +yWwyALEjk56vC/EcexQEW3PghskxE2nK8wzxTLlr6+Zv1xR0smEZdAu/bLvVaNUgAD5 iHdw== X-Gm-Message-State: AKaTC02Fdx0NYDGNIgH26WxpwzL/r28qduma3Ox5IeWKTBhecxPHDGgnDb+BtmAFy0HJPFVyUJLmJB05E63UyLyE X-Received: by 10.55.42.196 with SMTP id q65mr43764656qkq.267.1480957689221; Mon, 05 Dec 2016 09:08:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.146.246 with HTTP; Mon, 5 Dec 2016 09:08:08 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Mikael_St=C3=A5ldal?= Date: Mon, 5 Dec 2016 18:08:08 +0100 Message-ID: Subject: Re: Modules for SQL and MOM/JMS To: Log4J Developers List Content-Type: multipart/alternative; boundary=001a11495cf6fede6d0542ec54c4 archived-at: Mon, 05 Dec 2016 17:08:36 -0000 --001a11495cf6fede6d0542ec54c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I don't think we should create a new module just to save a single digit number of KB in core. On Mon, Dec 5, 2016 at 5:42 PM, Gary Gregory wrote= : > On Mon, Dec 5, 2016 at 8:25 AM, Matt Sicker 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 str= ong >> 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 =3D one jar level. At least in this > area. The one package =3D one jar would be one extreme way to deliver log= 4j > but the dependencies, yikes. > > Gary > > >> >> On 5 December 2016 at 03:30, Mikael St=C3=A5ldal >> 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 stu= ff >>> 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=C3=A5ldal < >>> mikael.staldal@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 >>>> 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-* module= s. >>>>> >>>>> 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 >>>>> 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 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 a= las, we >>>>>>> can really only guess. With that in mind, that layout sounds like i= t makes >>>>>>> sense, though calling it "log4j-db" is somewhat confusing. I'd pref= er 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 sam= e >>>>>>> pattern. >>>>>>> >>>>>>> On 4 December 2016 at 15:40, Gary Gregory >>>>>>> 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 < >>>>>>>> garydgregory@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 < >>>>>>>>> garydgregory@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 < >>>>>>>>>> garydgregory@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 >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> As for SQL, the JDBC one doesn't have any dependencies, so tha= t >>>>>>>>>>>> could stay in core if desired, but the JPA one does require ad= ditional 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 eith= er mean a >>>>>>>>>>>> mongo and couch component, or it could also mean an additional= nosql-common >>>>>>>>>>>> component (unless the abstract classes were put into log4j-cor= e). >>>>>>>>>>>> >>>>>>>>>>>> On 4 December 2016 at 12:44, Gary Gregory < >>>>>>>>>>>> garydgregory@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 mak= es sense. The >>>>>>>>>>>>> overall idea is to make core lighter. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Matt Sicker >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> E-Mail: garydgregory@gmail.com | ggregory@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: garydgregory@gmail.com | ggregory@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 >>>>> >>>> >>>> >>>> >>>> -- >>>> [image: MagineTV] >>>> >>>> *Mikael St=C3=A5ldal* >>>> Senior software developer >>>> >>>> *Magine TV* >>>> mikael.staldal@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=C3=A5ldal* >>> Senior software developer >>> >>> *Magine TV* >>> mikael.staldal@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 >> > > > > -- > E-Mail: garydgregory@gmail.com | ggregory@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 > --=20 [image: MagineTV] *Mikael St=C3=A5ldal* Senior software developer *Magine TV* mikael.staldal@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. --001a11495cf6fede6d0542ec54c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think we should create a new module just to sa= ve a single digit number of KB in core.
On Mon, Dec 5, 2016 at 5:42 PM, Gary Gregory <garydgregory@gmail.com> wrote:
On Mon, Dec 5, 2016 at 8:25 AM, Matt Sicker <boards@g= mail.com> wrote:
I agree with Mikael here. It would be nice to i= nclude the abstract base classes in log4j-core if they're dependency-fr= ee, but I don't have a strong opinion on whether to make it its own mod= ule.

Also, yes, log4j-nosql should be split along with t= he other modules.

Ah, ri= ght, dependencies. So:

= log4j-db
log4j-db-nosql
<= div style=3D"font-size:12.8px">log4j-db-nosql-counchdb
log4j-db-nosql-mongodb
log4j-db-jdbc
<= div>log4j-db-jpa

If we really want to thin our core, that justifies having=C2=A0= log4j-db and=C2=A0log4j-db-nosq.

Then we are al= most at the one package =3D one jar level. At least in this area. The=C2=A0= one package =3D one jar=C2=A0would be one extreme way to deliver log4j= but the dependencies, yikes.

<= span style=3D"font-size:12.8px">Gary
=C2=A0
=

On 5 December 2016 at 03:30, Mikael St=C3=A5ldal <mikael.staldal= @magine.com> wrote:
I would prefer the modules to be named like th= is to make names less clumsy:

log4j-jdbc
log4j-jpa
<= span style=3D"font-size:12.8px">log4j-jms
log4j-kafka
log4j-z= eromq (better than log4j-jeromq)

It seems like the proposed log4j= -db module would be very small and not have any external dependencies? In t= hat case I suggest we keep that stuff in log4j-core to avoid creating too m= any modules. We should only create new modules if they have external depend= encies 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=C3=A5ldal <mikael.staldal@magine.com> wrote:
I think we should focus on splitting into modules now, and worry a= bout repos later.



On Mon, Dec 5, 2016= at 6:29 AM, Gary Gregory <garydgregory@gmail.com> wrot= e:
Po= ssible 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, Zero= MQ and Kafka appenders do not share code but we could leave room for that.<= /div>

log4j-mom (not needed ATM)
log4j-mom= -jms
log4j-mom-kafka
log4j-mom-zeromq (or log4j-mom= -jeromq)<= br>

Gary

On Sun, Dec 4, 2016 at 3= :46 PM, Gary Gregory <garydgregory@gmail.com> wrote:
Hm:=C2= =A0NoSqlDatabaseManager extends AbstractDatabaseManager, so log4j-nosql wou= ld depend on log4j-db unless we leave AbstractDatabaseManager and friends i= n core.

Gary

On Sun, Dec 4, 2016 at 1:54 PM, Matt Sicker <boards@g= mail.com> wrote:
I wish we had a better way to gauge what plugin= s 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 co= nfusing. I'd prefer the name had some sort of indicator that it wasn= 9;t a standalone module as it wouldn't have any concrete plugins in it.=

Also, would log4j-nosql need to depend on log4j-db? Cou= ld be a nice opportunity for refactoring if necessary as they all follow th= e same pattern.

On 4 December 2016 at 15:40, Gary Gregory <garydgr= egory@gmail.com> wrote:
OK, I have a log4j-sql module split out lo= cally. But it seems we need instead:

- log4j-db (commons= code, depends log4j-core)
- log4j-jdbc (JDBC only, depends on lo= g4j-db)
- log4j-jpa (JPA only, depends on log4j-db)
I would also repackage these out of .core.

=
Thoughts?
<= div>
Gary

On Sun, Dec 4, 2016 at 1:28 PM, Gary Gregory &= lt;garydgregory= @gmail.com> wrote:
Note the common code in .core.db for .core.db.j= dbc and .core.db.jpa. It seems just that little bit should go in its own mo= dule or stay in core.

Gary

= On Sun, Dec 4, 2016 at 1:15 PM, Gary Gregory <garydgregory@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
<= /span>
=

On Sun, Dec 4, 20= 16 at 1:08 PM, Gary Gregory <garydgregory@gmail.com> wr= ote:
= Hm... this is also an opportunity to pick more precise names: log4j-jdbc an= d log4j-jpa

Gary
<= div>

On Sun, Dec 4, 2016 at 12:5= 6 PM, Matt Sicker <boards@gmail.com> wrote:
As for SQL, the JDBC o= ne 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 on= es, again, it would be nice to split those up so that there aren't opti= onal dependencies. That would either mean a mongo and couch component, or i= t could also mean an additional nosql-common component (unless the abstract= classes were put into log4j-core).
<= br>
On 4 December 2016 at 12:44, Gary Grego= ry <garydgregory@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 c= ore lighter.



--
Matt Sicker <boards@gmail.com>



--



--



--
=



--
=



<= /div>--
Matt Sicker <boards@gmail.com>



--



--
=



<= /div>--
3D=

Mikael St=C3=A5ldal
Senior software developer

Magine TV
mikael.s= taldal@magine.com=C2=A0 =C2=A0=C2=A0
Grev Turegatan 3 =C2=A0|=C2=A0114 46 St= ockholm, Sweden=C2=A0 | =C2=A0 www.magine.com

Privilege= d and/or Confidential Information may be contained in this message. If=20 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,=C2=A0
you should destroy this message and kindly notify the sender by reply ema= il. =C2=A0=C2=A0



--
<= div dir=3D"ltr">
3D"MagineTV"

Mikael St=C3=A5ldal
Senior software developer

Magine TV
mikael.s= taldal@magine.com=C2=A0 =C2=A0=C2=A0
Grev Turegatan 3 =C2=A0|=C2=A0114 46 St= ockholm, Sweden=C2=A0 | =C2=A0 www.magine.com

Privilege= d and/or Confidential Information may be contained in this message. If=20 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,=C2=A0
you should destroy this message and kindly notify the sender by reply ema= il. =C2=A0=C2=A0



<= /div>--
Matt Sicker <boards@gmail.com>


--
3D"Magin=

Mikael St=C3=A5ldal
Senior software developer

Magine TV
mikael.s= taldal@magine.com=C2=A0 =C2=A0=C2=A0
Grev Turegatan 3 =C2=A0|=C2=A0114 46 St= ockholm, Sweden=C2=A0 | =C2=A0 www.magine.com

Privilege= d and/or Confidential Information may be contained in this message. If=20 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,=C2=A0
you should destroy this message and kindly notify the sender by reply ema= il. =C2=A0=C2=A0
--001a11495cf6fede6d0542ec54c4--