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
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 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 wrote:
>
> Is this worthy doing in 2.0? In 3 we can do whatever we want IMO.
>
> Gary
>
>> On Sat, Mar 7, 2020, 23:2
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 o
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
> private
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 really
-core-spi or whatever the name, making 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
>
;
> > > 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 Ap
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
> > rather than attempting the full on modularization
h 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 at 11:56, Matt Sicke
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 part of the problem
va 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 wrote:
>
> > I doubt Google uses Git then.
> >
> > One of the main goals of separating repositor
d 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.
> >
S 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 wrote:
>
>> I doubt Google uses Git then.
&g
se 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
rather than attempting the full on modularization all in one go.
On 30 April 2017 at 11:56,
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 part of the problem there is
that for some reason, the release process requires running all the tests
and whatnot at least 3 times or more.
On 30 April 2
Maybe more than one repo isn't such a good idea? I hear Google uses a
single repo for all their code...
Gary
On Apr 30, 2017 9:41 AM, "Matt Sicker" wrote:
> I've noticed just with the Scala repo that integrating various repositories
> into a single coherent website is not so easy anymore (and i
I've noticed just with the Scala repo that integrating various repositories
into a single coherent website is not so easy anymore (and it wasn't really
all that easy in the first place). While it may be possible to manage each
repository's website individually and use symlinks in the svn repo to ke
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
> discussions and documen
We are going to have to prefix "module" with "Java" or "Maven" in
discussions and documentation to avoid confusion from now on...
Gary
On Apr 25, 2017 10:59 AM, "Matt Sicker" wrote:
> If you browse around the Java 9 javadocs, you'll see that they split things
> up by module there as well. With
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 at
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 wrote:
>
> Wh
17 at 4:03 PM, Gary Gregory <
> > > > garydgreg...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > We should have consensus on the big picture here... are we
> all
> > Ok
> > > > >
ng _required_ dependencies?
> > > > > > >
> > > > > > > Gary
> > > > > > >
> > > > > > > On Apr 25, 2017 6:57 AM, "Remko Popma"
> > > > wrote:
> > > > > > >
> > > >
icture here... are we all
>> Ok
>> > > with
>> > > > > the
>> > > > > > idea of all modules only having _required_ dependencies?
>> > > > > >
>> > > > > > Gary
>> > > > &
quot;
> > > wrote:
> > > > > >
> > > > > > > Nice analysis Mikael!
> > > > > > >
> > > > > > > I'm a bit fuzzy on log4j-spi, what was that for again? The list
> > > says
> > > > &g
> > > Nice analysis Mikael!
> > > > > >
> > > > > > I'm a bit fuzzy on log4j-spi, what was that for again? The list
> > says
> > > > > "core
> > > > > > will depend on spi" but I think it's worth maki
; > wrote:
> > > > >
> > > > > > Nice analysis Mikael!
> > > > > >
> > > > > > I'm a bit fuzzy on log4j-spi, what was that for again? The list
> > says
> > > > > "core
> > > >
og4j-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
> 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?
> > > >
> > > &g
> 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
> > &g
re
> > 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 sh
ile) 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 guess it depends on
> > what we&#
t; >
> > 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
> > modularization: do we want to red
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?
>
>
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
> wrote:
>
>> And all of that s
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:
>
> > I guess that log4-core will become:
> >
> >- lo
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 modularization:
do we want to reduce core to its absolute minimum or are we
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)
>- log4j-json (JsonLayout)
>- log4j
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?)
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, concretely?
>
> Matt mentioned
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 idea how you would build the mo
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
module-in
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 wrote:
> I
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
*
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
beco
The general idea I had was that if you include log4j-core in your
dependencies, you'll get log4j-api, log4j-spi, and most of the existing
functionality you already get access to in log4j-core currently. We'd split
out the bits that have extra dependencies for the most part which generally
revolves
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?
>
> Matt mentioned the Stack
How many new modules are we talking about, concretely?
Matt mentioned the StackOverflow questions about transitive dependencies
etc, but I imagine splitting log4j-core into 5 or more new modules will
also cause confusion... It won't be trivial for users to figure out which
of the many modules they
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. Then, if they don’t seem to be
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 an
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 repository with synchronize
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 mostly) and other log4
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 depend on log4j-spi (and
> probab
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 should
> probably b
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 04
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 repository with synchronized versioning and
releases, at least for the 2.9 rel
We have to do something. I am about 3/4 of the way creating java9 modules and I
am not happy with core at all. Far too many classes have to be exported as you
can only name packages, not classes.
I think all the configuration stuff will need to stay in core, which means the
optional dependency
I think I brought this topic up like 3 years ago when I was working on
initial OSGi support, but now that we have 3 more years worth of code
additions and optional features, I think this might be a more appropriate
time to discuss it again in light of experience.
Building log4j-core itself already
59 matches
Mail list logo
