logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: Layout package
Date Thu, 22 Aug 2013 11:37:00 GMT
Ok, so after a little pause, here is where we are: there are no code
changes for this yet and we are still inconsistent. The "core" jar is an
implementation of the API in the "api" jar. As such, it seems over the top
go along the lines of the SPI/internal suggestion I made, we would then end
up, in the "impl" jar (aka "core"), with another split b/w an API and an
impl. This would only be useful for "core/impl" developers, or extenders of
the core. What I am after is clarity and consistency, so whether the
interfaces are in the root core package or in the subpackages is a style
issue. I'd like for us to pick one, clean things up and stick to it.

Thoughts?

1) interfaces A, B, ... in o.a.l.l.core
2) interfaces in o.a.l.l.core.a, .b, ...

Gary



On Sat, Aug 17, 2013 at 3:40 AM, Ralph Goers <ralph.goers@dslextreme.com>wrote:

> Yeah. That is what package-info.java is for isn't it?  Today we are pretty
> terse.
>
> Ralph
>
> On Aug 17, 2013, at 12:21 AM, Gary Gregory wrote:
>
> On Sat, Aug 17, 2013 at 2:59 AM, Ralph Goers <ralph.goers@dslextreme.com>wrote:
>
>> Well then, I suppose we could move things like Configurator and
>> Configuration to the core package and then move all the sub packages under
>> "internal", but that just seems like a lot of busy work when we could just
>> as easily declare in a read me that everything in any sub package is
>> internal.
>>
>
> Fair enough, some package level Javadoc should help there.
>
> Gary
>
>
>>
>> On Aug 16, 2013, at 11:51 PM, Gary Gregory wrote:
>>
>> The way I've seen this done in Java is to use a package called ".spi",
>> the Service Provider Interface package. Internal stuff is in ".internal"
>> packages (which Eclipse uses a lot). When you import something from a
>> ".internal" package, you know you're not on solid ground. I've also seen
>> ".impl" packages, which IMO is not a good name. I've never seen a .private.
>> package though.
>>
>> Gary
>>
>>
>> On Sat, Aug 17, 2013 at 2:44 AM, Ralph Goers <ralph.goers@dslextreme.com>wrote:
>>
>>> I guess what you are after is a way to make clear what are the
>>> interfaces and classes developers can use when creating their own
>>> components.  I originally planned on those being in the main core package
>>> but I clearly didn't include everything that could be there.
>>>  Unfortunately, this is one of the things Java isn't particularly good at.
>>>  I don't know of a good way to indicate what is internal vs OK to use other
>>> than comments.
>>>
>>> Ralph
>>>
>>> On Aug 16, 2013, at 11:37 PM, Gary Gregory wrote:
>>>
>>> On Sat, Aug 17, 2013 at 1:41 AM, Ralph Goers <ralph.goers@dslextreme.com
>>> > wrote:
>>>
>>>> Yeah. StrLookup should be moved up to core.
>>>>
>>>
>>> I tried it and feels arbitrary when I look at all the subpackages and
>>> wonder which of all the other interfaces should also be moved up.
>>>
>>> If we had a specific .spi package it might be better, but that does not
>>> really make sense in the Core module, right?
>>>
>>> It seems neat and tidy if an interface foo is in the .foo package.
>>>
>>> Gary
>>>
>>>>
>>>> Ralph
>>>>
>>>> On Aug 16, 2013, at 10:17 PM, Gary Gregory wrote:
>>>>
>>>> > It seems inconsistent to me, but then StrLookup should be moved up to
>>>> > match the style of the others?
>>>> >
>>>> > Gary
>>>> >
>>>> > On Aug 16, 2013, at 22:05, Ralph Goers <ralph.goers@dslextreme.com>
>>>> wrote:
>>>> >
>>>> >> StrLookup
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>> >
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Mime
View raw message