On 10 February 2014 12:32, Davide D'Alto <daltodav...@gmail.com> wrote: > I can work on this today and start to plan the release for Wednesday. > > I don't think this change should block the next release though. > > It would also be nice to include this: > https://github.com/hibernate/hibernate-ogm/pull/282 > so that people can actually use the enitty manager to create queries > > > > On Mon, Feb 10, 2014 at 10:50 AM, Gunnar Morling <gun...@hibernate.org>wrote: > >> Hi, >> >> One thing I'd like to address before doing the next OGM release is the >> structure of public packages in the datastore-specific modules. >> >> Currently we have the following structure: >> >> * org.hibernate.ogm.datastore.<infinispan|ehcache|mongodb|...> >> * org.hibernate.ogm.dialect.<infinispan|ehcache|mongodb|...> >> * org.hibernate.ogm.logging.<infinispan|ehcache|mongodb|...> >> ... >> >> I think it makes sense to pull the datastore-specific package up one level, >> moving all the types of a backend under one shared super-package. So it >> would like this instead: >> >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.datastore >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.dialect >> * org.hibernate.ogm.<infinispan|ehcache|mongodb|...>.logging >> ... >> >> The reason I'm bringing this up is that we're introducing new user-exposed >> types with that release: the store identifier types (MongoDB, CouchDB etc.) >> and their properties class (MongoDBProperties, CouchDBProperties etc.). So >> if we agree to do this change it would be good to do it now before having >> to move these public types later on.
Since you mention users as a reason for this change, I've to admit that I don't see how it helps users. Personally I think it's quite helpfull to have the package to help me quickly identify which dialects I have available; we should also expect potentially to have sub-types in the future like org.hibernate.ogm.datastore.infinispan.local org.hibernate.ogm.datastore.infinispan.clusterable org.hibernate.ogm.datastore.cassandra.embedded Since I don't see a value advantage in changing the packages, I'll side with the "resistance against change" party, unless you share some compelling argument of course :-) the "logging" case is different: that's a private package so we might want to highlight that in the package structure. >> Another question is how to differentiate between public and internal >> packages, but I think we can discuss this later on, as a change would only >> affect internal packages. Emmanuel and I couldn't agree on a best approach >> when discussing it shortly, so this might need some more time :) >> >> Any thoughts? I'd move things to .impl for the private ones, leaving all others as they are. That should also simplify for example a filtering rule for the javadoc generation. -- Sanne >> >> --Gunnar >> _______________________________________________ >> 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 _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
