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

[Sanne Grinovero]

2011/5/17 Hardy Ferentschik <hardy at hibernate.org>:
> 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.

+1
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.

Sanne

>
> 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.
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>