[hibernate-dev] api/spi/internal package split

Steve Ebersole steve at hibernate.org
Tue May 17 11:17:58 EDT 2011

The use of annotations is an interesting idea.  I had not considered that.

I'd also want the javadocs to accurately reflect this distinction.  Are 
annotations available to doclets?  I am thinking perhaps not, based on 
my knowledge of @Deprecated

On 05/17/2011 09:45 AM, Hardy Ferentschik wrote:
> Hi,
> sorry for reviving this thread so late, but I only now gained more
> experience with
> this package splitting.
> Personally I don't like it too much. I partly understand the reason, but
> I am not
> sure if this religious package naming makes sense.
> As already mentioned in this thread, there is the issue of package
> explosion.
> Secondly, it is often no clear cut between spi/api/internal and lastly I
> find
> it now much harder to have a mental picture of the structural
> organization of
> the software. All I see in the package explorer are spis, apis and
> internals.
> Don't get me wrong, some of the package changes are sensible, but should
> we force
> this split on each single level?
> An idea which came up was whether we couldn't use an annotation
> processor (yes
> another one ;-). We could define custom annotations (@SPI, @PublicApi)
> which the
> annotation processor could pick up on and create the correct META-INF or
> whatever is needed.
> Comments?
> --Hardy
> On Mon, 28 Mar 2011 19:48:02 +0200, Steve Ebersole <steve at hibernate.org>
> wrote:
>> On Monday, March 28, 2011, at 12:36 pm, Emmanuel Bernard wrote:
>>> I'd say I like the current approach better than using spi / internal
>>> as top
>>> level.
>>> The only think I would change is rename internal to some shorter
>>> version:
>>> - impl
>>> - private
>>> - hidden
>>> - ?
>>> Another discussion we had on HSearch is whether or not use internal
>>> on the
>>> package name that is always bound to be private. For example say
>>> org.hibernate.search.util only contains private stuff, should we have
>>> org.hibernate.search.util.internal or can we keep
>>> org.hibernate.search.util
>>> My opinion is that we should be consistent and use
>>> org.hibernate.search.util.internal
>> Totally agree, especially if you start thinking about extracting these
>> into
>> separate jars for osgi. You need some kind of consistency in order to
>> identify what goes where without having to individually identify
>> class-by-
>> class, which of course noone wants to mainatain.

Steve Ebersole <steve at hibernate.org>

More information about the hibernate-dev mailing list