[hibernate-dev] api/spi/internal package split
sanne at hibernate.org
Tue May 17 11:15:19 EDT 2011
2011/5/17 Hardy Ferentschik <hardy at hibernate.org>:
> 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
> Secondly, it is often no clear cut between spi/api/internal and lastly I
> it now much harder to have a mental picture of the structural organization
> the software. All I see in the package explorer are spis, apis and
> 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
> 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.
anything which will read our annotations and produce what
osgi/jbossmodules need in the jar would be awesome.
An annotation processor would work, but I'd be fine with alternatives too.
I think this would be a great idea; it doesn't necessarily mean to
revert or to not apply the current package name changes,
this would be an added flexibility so that we can declare stuff as
being public/private/spi without having to change package names.
For example in some cases I'd prefer to edit a list of public classes
than to refactor the project; it doesn't need to be like that, but
having the options would be cool.
> On Mon, 28 Mar 2011 19:48:02 +0200, Steve Ebersole <steve at hibernate.org>
>> 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
>>> The only think I would change is rename internal to some shorter
>>> - impl
>>> - private
>>> - hidden
>>> - ?
>>> Another discussion we had on HSearch is whether or not use internal on
>>> 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
>>> My opinion is that we should be consistent and use
>> Totally agree, especially if you start thinking about extracting these
>> separate jars for osgi. You need some kind of consistency in order to
>> identify what goes where without having to individually identify
>> class, which of course noone wants to mainatain.
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
More information about the hibernate-dev