Re: Modularization

Sounds like a great idea to me. I’ve been trying to use package private classes where possible in the bean branch which would fit very well with that pattern. Hopefully we can arrange classes in such a way to avoid needing to export the internal ones at all like you suggested. On Sun, Mar 8, 2020

Re: Modularization

Rats. Substitute “no plans” with “only plans”. Ralph > On Mar 8, 2020, at 6:31 AM, Apache wrote: > > I have no plans to do this in master. One of the main goals of 3.0 is to be > fully modularized. This is just one part of that. > > Ralph > >> On Mar 8, 2020, at 5:26 AM, Gary Gregory

Re: Modularization

I have no plans to do this in master. One of the main goals of 3.0 is to be fully modularized. This is just one part of that. Ralph > On Mar 8, 2020, at 5:26 AM, Gary Gregory wrote: > > Is this worthy doing in 2.0? In 3 we can do whatever we want IMO. > > Gary > >> On Sat, Mar 7, 2020,

Re: Modularization

Is this worthy doing in 2.0? In 3 we can do whatever we want IMO. Gary On Sat, Mar 7, 2020, 23:24 Ralph Goers wrote: > I started looking at log4j-core in master today with an eye towards > creating the module-info.java file. As I went through it I realized we > would have to expose almost all

Re: Modularization

sounds good to me. On Sun, 8 Mar 2020 at 04:24, Ralph Goers wrote: > I started looking at log4j-core in master today with an eye towards > creating the module-info.java file. As I went through it I realized we > would have to expose almost all of the packages because we have co-mingled >

Modularization

I started looking at log4j-core in master today with an eye towards creating the module-info.java file. As I went through it I realized we would have to expose almost all of the packages because we have co-mingled private implementations along with public interfaces and abstract class. We

Re: [Log4j] Plans for modularization

ng it easier for other > > modules to release on their own without being synced up with log4j-core > > versions > > > > With the current JPMS drama going on, it seems like we may have more time > > before Java 9 is released, so we should have time to follow this path > &

Re: [Log4j] Plans for modularization

ing synced up with log4j-core > versions > > With the current JPMS drama going on, it seems like we may have more time > before Java 9 is released, so we should have time to follow this path > rather than attempting the full on modularization all in one go. > > On 30 April 2017 a

Re: [Log4j] Plans for modularization

Google does not use Git, I think they use some internally developed VCS. On Sun, Apr 30, 2017 at 6:56 PM, Matt Sicker wrote: > I doubt Google uses Git then. > > One of the main goals of separating repositories is to make release > management easier so we can RERO more! Though

Re: [Log4j] Plans for modularization

e > before Java 9 is released, so we should have time to follow this path > rather than attempting the full on modularization all in one go. > > On 30 April 2017 at 11:56, Matt Sicker <boa...@gmail.com> wrote: > > > I doubt Google uses Git then. > > > > One of

Re: [Log4j] Plans for modularization

> With the current JPMS drama going on, it seems like we may have more time > before Java 9 is released, so we should have time to follow this path > rather than attempting the full on modularization all in one go. > > On 30 April 2017 at 11:56, Matt Sicker <boa...@gmail.com> wrote: &

Re: [Log4j] Plans for modularization

Ideally, the two will align, just like the OSGi modules (which tend to directly correspond with maven modules since that's how they're normally assembled). On 25 April 2017 at 13:39, Gary Gregory wrote: > We are going to have to prefix "module" with "Java" or "Maven" in

Re: [Log4j] Plans for modularization

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

Re: [Log4j] Plans for modularization

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

Re: [Log4j] Plans for modularization

dencies? >> > > > > > >> > > > > > Gary >> > > > > > >> > > > > > On Apr 25, 2017 6:57 AM, "Remko Popma" <remko.po...@gmail.com> >> > > wrote: >> > > > >

Re: [Log4j] Plans for modularization

t; > > Gary > > > > > > > > > > > > On Apr 25, 2017 6:57 AM, "Remko Popma" <remko.po...@gmail.com> > > > wrote: > > > > > > > > > > > > > Nice analysis Mikael! > > > > > > >

Re: [Log4j] Plans for modularization

gt; > > > > > > > On Apr 25, 2017 6:57 AM, "Remko Popma" <remko.po...@gmail.com> > > wrote: > > > > > > > > > > > Nice analysis Mikael! > > > > > > > > > > > > I'm a bit fuzzy on log4j-spi, what was that for

Re: [Log4j] Plans for modularization

4j-spi, what was that for again? The list says > > > "core > > > > will depend on spi" but I think it's worth making an effort to > ensure > > > that > > > > basic (file) logging behavior only needs core+API... Why does spi > need > > to >

Re: [Log4j] Plans for modularization

on spi" but I think it's worth making an effort to > ensure > > > that > > > > basic (file) logging behavior only needs core+API... Why does spi > need > > to > > > > be separated from core? > > > > > > > > My first thought a

Re: [Log4j] Plans for modularization

will depend on spi" but I think it's worth making an effort to ensure > > that > > > basic (file) logging behavior only needs core+API... Why does spi need > to > > > be separated from core? > > > > > > My first thought about jdbc was that since jdbc doesn't requir

Re: [Log4j] Plans for modularization

an effort to ensure > that > > basic (file) logging behavior only needs core+API... Why does spi need to > > be separated from core? > > > > My first thought about jdbc was that since jdbc doesn't require external > > dependencies we should probably leave it in core. I

Re: [Log4j] Plans for modularization

ed to > > be separated from core? > > > > My first thought about jdbc was that since jdbc doesn't require external > > dependencies we should probably leave it in core. I guess it depends on > > what we're trying to achieve with (or how far we want to take) the > >

Re: [Log4j] Plans for modularization

doesn't require external > dependencies we should probably leave it in core. I guess it depends on > what we're trying to achieve with (or how far we want to take) the > modularization: do we want to reduce core to its absolute minimum or are we > aiming to split off external dependencies?

Re: [Log4j] Plans for modularization

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 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

Re: [Log4j] Plans for modularization

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 wrote: > And all of that should stay in the same repo IMO. > > Gary > > On Apr 25, 2017 2:51 AM, "Mikael Ståldal" > wrote: > > >

Re: [Log4j] Plans for modularization

ught about jdbc was that since jdbc doesn't require external dependencies we should probably leave it in core. I guess it depends on what we're trying to achieve with (or how far we want to take) the modularization: do we want to reduce core to its absolute minimum or are we aiming to split off

Re: [Log4j] Plans for modularization

And all of that should stay in the same repo IMO. Gary On Apr 25, 2017 2:51 AM, "Mikael Ståldal" wrote: > I guess that log4-core will become: > >- log4j-core (will depend on log4j-spi) >- log4j-spi >- log4j-csv >- log4j-xml (XmlLayout) >-

Re: [Log4j] Plans for modularization

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?)

Re: [Log4j] Plans for modularization

I don't think it will be more difficult to figure out which of the modules to use, than to figure out which optional 3rd party dependencies they need to include today. On Mon, Apr 24, 2017 at 7:43 PM, Remko Popma wrote: > How many new modules are we talking about,

Re: [Log4j] Plans for modularization

It'd probably be confusing to make a log4j-core-all that only works with Java 7 and 8, too, so it'd have to be doable somehow. I wonder how shaded/shadowed applications are supposed to work in Java 9? On 24 April 2017 at 14:12, Ralph Goers wrote: > Yeah, I have no

Re: [Log4j] Plans for modularization

Yeah, I have no idea how you would build the module-info.class file. module-info.java is compiled by the compiler and it performs checks to make sure the things being exported are really there. So you would need to have a maven module that unpacks all the classes and then compiles the

Re: [Log4j] Plans for modularization

It doesn't sound like there's a proper way to export a Java 9 module from two separate JARs, though I'm not clear on the details. If we package up the modules into a sort of log4j-core-all artifact, that'd be an assembly detail for distribution. On 24 April 2017 at 13:19, Remko Popma

Re: [Log4j] Plans for modularization

I must be missing something, I don't see the problem. Users wouldn't have both the combined jar and the single-module jars on the classpath together, so there should not be an issue... For example, assume our current log4j-core jar is split up into * log4j-core-slim * log4j-core-appender-db *

Re: [Log4j] Plans for modularization

In theory I agree with this but the devil is in the details. For example, we want to be able to say that Log4j requires NO third party dependencies but that we support and take advantage of features provided by third-party software. This means that even though the third-party jars will now

Re: [Log4j] Plans for modularization

Guess what? If I am understanding Stephen correctly uber jars are not going to work as you can’t have multiple modules that export the same package. Ralph > On Apr 24, 2017, at 10:43 AM, Remko Popma wrote: > > How many new modules are we talking about, concretely? > >

Re: [Log4j] Plans for modularization

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 wrote: > I would prefer a hybrid approach. First things should be moved to > separate modules.

Re: [Log4j] Plans for modularization

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

Re: [Log4j] Plans for modularization

On Apr 24, 2017 2:38 AM, "Mikael Ståldal" 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

Re: [Log4j] Plans for modularization

I guess that log4j-core would include other Log4j implementation stuff also (that plugins does not need to depend on). On Mon, Apr 24, 2017 at 4:48 PM, Matt Sicker wrote: > That would be the goal. Then we can have a log4j-core which has all the > main plugins (file-related

Re: [Log4j] Plans for modularization

That would be the goal. Then we can have a log4j-core which has all the main plugins (file-related mostly) and other log4j addons for the 3rd party dependency ones. On 24 April 2017 at 09:47, Mikael Ståldal wrote: > I guess this means that a plugin only needs to

Re: [Log4j] Plans for modularization

I guess this means that a plugin only needs to depend on log4j-spi (and probably on log4j-api), not on log4j-core or anything else log4j-*. That would be good. On Mon, Apr 24, 2017 at 4:44 PM, Matt Sicker wrote: > Keeping configuration/plugin processing code inside log4j-spi

Re: [Log4j] Plans for modularization

Keeping configuration/plugin processing code inside log4j-spi should probably be marked clearly which classes are public APIs and which aren't then. I'm not sure how many classes would need to be moved around, but that will require some experimentation to figure out anyways. On 24 April 2017 at