Re: [hibernate-dev] api/spi/internal package split
2011/5/17 Hardy Ferentschik <hardy(a)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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev