On 10 February 2014 12:32, Davide D'Alto <daltodavide(a)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 <gunnar(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev