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 at 09:55 Apache <[email protected]> wrote: > Rats. Substitute “no plans” with “only plans”. > > Ralph > > > On Mar 8, 2020, at 6:31 AM, Apache <[email protected]> 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 <[email protected]> > wrote: > >> > >> 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 <[email protected]> > 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 implementations along with public interfaces and abstract > class. We > >>> really can’t move the public classes as user’s are currently > referencing > >>> them so I am proposing that we move the private classes. I already > started > >>> that with LogBuilder by creating a directory named “internal” off of > core. > >>> Rather than having internal directories all over the place I am > thinking we > >>> should mimic the same existing package structure under the internal > >>> directory and move private classes there. > >>> > >>> Thoughts? > >>> > >>> Ralph > >>> > > > -- Matt Sicker <[email protected]>
