Re: Modules for SQL and MOM/JMS

>From my POV it's primarily about reducing/managing dependencies. If we can save A LOT in terms of size, that's relevant too, but not only to save a little. If you are counting KBs of jar size, you should probably use *ProGuard* or something like that. On Mon, Dec 5, 2016 at 6:23 PM, Gary Gregory

Re: Modules for SQL and MOM/JMS

What about log4j-mongodb and log4j-couchdb? I doubt anyone is using both at the same time. On 5 December 2016 at 18:14, Remko Popma wrote: > Too fine grained dependencies will be difficult for users. I like > > log4j-jdbc > log4j-jpa > log4j-jms > log4j-kafka > log4j-zeromq > > If these share an

Re: Modules for SQL and MOM/JMS

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 wrote: > > You don't need to include "nosql" in the spli

Re: Modules for SQL and MOM/JMS

By that, I mean the word "nosql". On 5 December 2016 at 11:54, Matt Sicker 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 wrote: > >> On Mon, Dec

Re: Modules for SQL and MOM/JMS

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 wrote: > On Mon, Dec 5, 2016 at 9:08 AM, Mikael Ståldal > wrote: > >> I don't think we should create a new module

Re: Modules for SQL and MOM/JMS

On Mon, Dec 5, 2016 at 9:08 AM, Mikael Ståldal 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,

Re: Modules for SQL and MOM/JMS

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

Re: Modules for SQL and MOM/JMS

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 strong > opinion on whether to make it its own module. > > Also, yes, log4j-nosql should be split alo

Re: Modules for SQL and MOM/JMS

On Mon, Dec 5, 2016 at 1:30 AM, Mikael Ståldal 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

Re: Modules for SQL and MOM/JMS

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. On 5 December 2016 at 03:30, Mikae

Re: Modules for SQL and MOM/JMS

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

Re: Modules for SQL and MOM/JMS

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 hint

Re: Modules for SQL and MOM/JMS

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 shar

Re: Modules for SQL and MOM/JMS

The sites should all link together seamlessly. As for speeding up the build, perhaps we should be profiling what parts are taking so long to build or execute. On 4 December 2016 at 17:36, Remko Popma wrote: > I worry that breaking the site up into multiple sub sites is going to make > the user

Re: Modules for SQL and MOM/JMS

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

Re: Modules for SQL and MOM/JMS

I worry that breaking the site up into multiple sub sites is going to make the user experience worse. It may make it difficult for users to find things. And I'm still not convinced that this will speed up the build Sent from my iPhone > On 5 Dec 2016, at 7:30, Apache wrote: > > I don’t t

Re: Modules for SQL and MOM/JMS

I don’t think each of those should be in a separate repository, but it would make sense to have a single repo with all of them as sub projects. We do need to determine how we are going to change the layout of the Log4j site to accommodate all of this as each repository will have its own Maven ge

Re: Modules for SQL and MOM/JMS

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

Re: Modules for SQL and MOM/JMS

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 a

Re: Modules for SQL and MOM/JMS

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 wrote: > Also: package names, it does not make sense to have JDBC and JPA code > under the .core. pac

Re: Modules for SQL and MOM/JMS

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 wrote: > Hm... this is also an opportunity to

Re: Modules for SQL and MOM/JMS

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 that could stay > in core if desired, but the JPA one does require additional Java EE APIs

Re: Modules for SQL and MOM/JMS

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 de

Re: Modules for SQL and MOM/JMS

The MOM appenders and such could be made into its own repo, possibly subcomponents within a general messaging repo. This would include JMS, Kafka, and JeroMQ as of now along with any other future additions. I'd prefer that the modules were small enough that they could stop relying on optional depe

Re: Modules

The performance regression tests would make sense to be moved to log4j-perf. We should include some sort of script or instructions on how to run the specific performance tests to verify performance hasn't gotten worse in each release. On 3 December 2016 at 22:43, Remko Popma wrote: > > On 1 Oct

Re: Modules

> On 1 Oct 2016, at 2:04, Ralph Goers wrote: > > Actually, I just created LOG4J2-1627 for this and I specifically did bring > Java 9 modules into the discussion because they should at least be considered > along with the Java 8 profiles. Right now I am sure we have stuff that would > create p

Re: Modules

I do like the idea of moving plugins that have optional dependencies into their own modules that have required dependencies. That would certainly make usage easier. On 3 October 2016 at 03:21, Mikael Ståldal wrote: > If we should reorganize the project, there is another issue we should > conside

Re: Modules

If we should reorganize the project, there is another issue we should consider: transitive dependencies Currently, log4j-core has quite some optional dependencies. I don't like that since the user needs to manually keep track of which transitive runtime dependencies to use, efficiently negating th

Re: Modules

> On 1 Oct 2016, at 13:05, Ralph Goers wrote: > > I don’t cut a release branch. The Maven release plugin updates the pom > versions, creates the release tag, and then changes the pom version to be a > snapshot. It then essentially does a mvn deploy on the tag. The release > plugin typically

Re: Modules

I don’t cut a release branch. The Maven release plugin updates the pom versions, creates the release tag, and then changes the pom version to be a snapshot. It then essentially does a mvn deploy on the tag. The release plugin typically performs a build against the snapshot to confirm the build

Re: Modules

On Fri, Sep 30, 2016 at 8:03 PM, Remko Popma wrote: > Thanks! > Were you thinking of doing a release as an "exercise" to improve the process? ;-) Gary > > Sent from my iPhone > > On 1 Oct 2016, at 11:34, Gary Gregory wrote: > > On Sep 30, 2016 7:15 PM, "Remko Popma" wrote: > > > > Can anyone

Re: Modules

Thanks! Sent from my iPhone > On 1 Oct 2016, at 11:34, Gary Gregory wrote: > > On Sep 30, 2016 7:15 PM, "Remko Popma" wrote: > > > > Can anyone send a link to the release procedures? > > http://wiki.apache.org/logging/Log4j2ReleaseGuide > > Gary > > > > Sent from my iPhone > > > > On 1 Oct 2

Re: Modules

On Sep 30, 2016 7:15 PM, "Remko Popma" wrote: > > Can anyone send a link to the release procedures? http://wiki.apache.org/logging/Log4j2ReleaseGuide Gary > > Sent from my iPhone > > On 1 Oct 2016, at 2:31, Ralph Goers wrote: > >> I would have a “core” project and an “extras”, “extensions” or s

Re: Modules

Can anyone send a link to the release procedures? Sent from my iPhone > On 1 Oct 2016, at 2:31, Ralph Goers wrote: > > I would have a “core” project and an “extras”, “extensions” or some other > name. They are all already separate jars. I just want to split them out > because they don’t (or

Re: Modules

Sent from my iPhone > On 1 Oct 2016, at 2:04, Ralph Goers wrote: > > Actually, I just created LOG4J2-1627 for this and I specifically did bring > Java 9 modules into the discussion because they should at least be considered > along with the Java 8 profiles. Right now I am sure we have stuff

Re: Modules

I would have a “core” project and an “extras”, “extensions” or some other name. They are all already separate jars. I just want to split them out because they don’t (or shouldn’t) change nearly as often as the core stuff - although we may get to the point where core is pretty stable and we are

Re: Modules

I think your opinion would change if you tried to do the release. Ralph > On Sep 30, 2016, at 10:05 AM, Gary Gregory wrote: > > Right, hence this thread ;-) I am not hot about having multiple builds FYIW. > > Gary > > On Fri, Sep 30, 2016 at 9:59 AM, Matt Sicker > w

Re: Modules

Oh, and FWIW, I have never really been interested in the uber jar. To me, the bom is really all that is required for that. Ralph > On Sep 30, 2016, at 10:04 AM, Ralph Goers wrote: > > Actually, I just created LOG4J2-1627 for this and I specifically did bring > Java 9 modules into the discuss

Re: Modules

Increased modularity is the OSGi way, but it's also a hard thing to convince people of. I've met many developers (notably Spring fanboys) that are still in a monolithic classpath mindset of "why bother splitting this up?" Anyways, Ralph, are you proposing spinning out the non-core stuff into a sin

Re: Modules

Right, hence this thread ;-) I am not hot about having multiple builds FYIW. Gary On Fri, Sep 30, 2016 at 9:59 AM, Matt Sicker wrote: > Oh wait, Ralph is talking about something else entirely. > > On 30 September 2016 at 11:58, Matt Sicker wrote: > >> I think log4j-nosql could be merged into l

Re: Modules

Actually, I just created LOG4J2-1627 for this and I specifically did bring Java 9 modules into the discussion because they should at least be considered along with the Java 8 profiles. Right now I am sure we have stuff that would create problems with trying to run in compact profiles 1 and 2.

Re: Modules

Oh wait, Ralph is talking about something else entirely. On 30 September 2016 at 11:58, Matt Sicker wrote: > I think log4j-nosql could be merged into log4j-core. > > On 30 September 2016 at 11:50, Gary Gregory > wrote: > >> Ralph recently mentions that he'd like some modules removed while Matt

Re: Modules

I think log4j-nosql could be merged into log4j-core. On 30 September 2016 at 11:50, Gary Gregory wrote: > Ralph recently mentions that he'd like some modules removed while Matt > mentioned merging some back into Core. > > Shall we discuss this on the ML instead of Jira? > > I could also see doin