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

[Emmanuel Bernard]

The annotation approach is an idea that I like conceptually and that some proposed (wo pushing it further so far). 
That being said, my work on classes split has shown me that you need to work a lot to get a decent split and a physical package makes it very clear that things are screwed or not yet in place. If I had to open each class to see if the dependency is public or not, I'm pretty sure I would not have succeeded.
I imagine that with enough tools, you could get a visualization of what's going on and reach the level of explicitness of the package split but somebody needs to write such a graphical or command line tool.
Also, such split might / will be consumed by a few processes down the road:
 - JavaDocs generation
 - product documentation
 - auditing tools for customers and support
 - Eclipse plugin to warn users

A pattern matching based tool is super easy to do. An annotation based matching tool (annotations not present on the client caller but on the actual framework classes) is a whole lot harder. Who is going to maintain this toolchain?

>From a user point of view, the package name is a clear distinction and a simple global project search can find all the culprit usages. Granted, an annotation processor can even raise compiler warns or errors but the user has to set them up. I see it as neutral to positive to the user if we go to the annotation processor.

If you feel strongly about it, go and run it by the tag list so that more people play with the idea.

Emmanuel

On 17 mai 2011, at 16:45, 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.
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev