I won't touch the modules. I think we need hash it out a little more and get a consensus.
If there are 2 modules: JPA and JDBC, then the generic .db package needs to stay in log4j-core. Which would be OK for now. Gary On Fri, Jan 12, 2018 at 11:16 PM, Remko Popma <[email protected]> wrote: > Okay perhaps just two modules then? > > By the way, I have work in progress on the high-precision time stamps that > would be impacted by this. I would like to avoid the merge conflict by > postponing this module breakdown until that is merged. Is that possible? > > (Shameless plug) Every java main() method deserves http://picocli.info > > > On Jan 13, 2018, at 14:33, Gary Gregory <[email protected]> wrote: > > > > The reason to split out JPA would be to avoid bringing in the dependency > to > > javax.persistenance which is not in the JRE. The JDBC API OTOH is in the > > JRE. > > > > Gary > > > >> On Fri, Jan 12, 2018 at 10:14 PM, Remko Popma <[email protected]> > wrote: > >> > >> How about moving all of these (generic database support, jdbc and jpa) > >> together into a single separate module? > >> > >> Something like: > >> > >> log4j-db > >> > >> I don’t see much value into splitting them up further, but perhaps > that’s > >> just me. > >> > >> Remko > >> > >> (Shameless plug) Every java main() method deserves http://picocli.info > >> > >>> On Jan 13, 2018, at 13:16, Gary Gregory <[email protected]> > wrote: > >>> > >>> Hi All: > >>> > >>> I wonder if we should move the JDBC Appender to its own module. > >>> > >>> Also wondering how we would then slice and dice the generic database > >>> support and the JPA Appender: > >>> > >>> - log4j-db > >>> - log4j-jdbc > >>> - log4j-jpa > >>> > >>> Those would all be small modules... > >>> > >>> ? > >>> > >>> Thank you, > >>> Gary > >> >
