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