2011/5/17 Hardy Ferentschik <ha...@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 <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. > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
