Create OSGi integration test project for all of Hibernate?
by Brett Meyer
ORM currently uses Arquillian to test hibernate-osgi (and afaik Validator does the same). Since at least ORM, Validator, and Search have moved or are moving towards supporting OSGi environments, would it make more sense to create hibernate/hibernate-osgi-integration-tests and wire it to a new CI job? Arguably, they shouldn't be considered a "unit test" to begin with, but that's up for debate. Thoughts?
Brett Meyer
Red Hat, Hibernate ORM
12 years, 3 months
Enabling all modules by default in a build
by Sanne Grinovero
In Hibernate Search there is a Maven module responsible for running
performance tests, which takes several minutes to run.
Since it's quite annoying for day to day development, and especially
during a release process as the process runs the tests multiple times,
the module is only enabled when explicitly selecting an ad-hoc Maven
profile.
I now just realized that by doing so, the Maven release process does
not correctly update the version of the module after a release: the
non-master CI jobs I just created fail to build as it refers to a
mismatched snapshot version (it happens to work on master by chance).
I'll fix the specific situation with an ad-hoc commit, but what's the
long term fix? Should we deprecate this kind of selection of built
modules?
This problem didn't affect the docs module as this is explicitly
enabled by the release process, but I really don't want to add an
additional half an our for the release process to run performance
tests.
I'm planning to have the module always run, so that at least it gets
compiled, and use the profile to set some environment options for
long/short duration. Good idea?
The fix to include documentation would probably need to wait migration
to asciidoc.
Cheers,
Sanne
12 years, 3 months
[OGM] Store-specific constants
by Gunnar Morling
Hi,
Davide brought up an interesting issue while reviewing a PR around the OGM
backend for CouchDB [1].
This PR makes use of the new Option API and allows to configure
CouchDB-specific settings in a safe way. For that purpose each dialect
needs to provide a sub-class of DatastoreConfiguration which is then passed
to configureDatastore() like this:
OgmSessionFactory factory = ...;
factory.configureDatastore( CouchDB.class )
.associationStorage( AssociationStorage.ASSOCIATION_DOCUMENT );
Now I had defined a constant on CouchDB for the property name for setting
the association storage type via OgmConfiguration, not being fully aware of
the existing interface Environment which defines some other constants such
as host name property etc.
Our question is, should now that we have the Option API and with it
store-specific DatastoreConfiguration types, the previously used
Environment interfaces be removed and their constants moved to the
corresponding DatastoreConfiguration type?
I think that'd make sense, also having in mind that we might expose
settings configured via OgmConfiguration via an equivalent global option at
some point. Also having distinct class names will be beneficial in polyglot
persistence scenarios where one needs to configure several stores.
What do others think?
--Gunnar
[1] https://github.com/hibernate/hibernate-ogm/pull/261
12 years, 3 months
To release a Hibernate Search 4.5.0.Alpha2?
by Sanne Grinovero
We need to align the 4.5 branch to latest ORM 4.3.
Considering the main theme for 4.5 is to keep up with JPA 2.1 and
latest WildFly, the branch is technically ready for a release.
Anything else that you would like to see fixed in this branch?
I have no problem in postponing the release to tomorrow if anyone
needs to send some PR soon, but if it takes longer I'd rather do
another release next week.. I don't want to prevent people from being
able to play with latest ORM just because our latest tag is not
compatible.
Sanne
12 years, 3 months
ORM 4.2.8.Final breaks the EntityKey API and thus HSearch
by Guillaume Smet
Hi all,
ORM 4.2.8.Final breaks the API of EntityKey as it removes tenantId
from the constructor.
Typically, in HSearch, we have the following call:
https://github.com/hibernate/hibernate-search/blob/master/orm/src/main/ja...
As 4.2.8.Final removes the tenantId from the EntityKey constructor,
you get a nice:
java.lang.NoSuchMethodError:
org.hibernate.engine.spi.EntityKey.<init>(Ljava/io/Serializable;Lorg/hibernate/persister/entity/EntityPersister;Ljava/lang/String;)V
at org.hibernate.search.query.hibernate.impl.PersistenceContextObjectsInitializer.initializeObjects(PersistenceContextObjectsInitializer.java:73)
>From my point of view, the best way to go would be to reintroduce the
constructor in EntityKey, mark it as deprecated and ignore the
tenantId.
I think it's worth a respin and a 4.2.8.SP1.
Thoughts?
(btw, totally unrelated, it would be nice to have examples of the new
Maven plugin for bytecode enhancement).
--
Guillaume
12 years, 4 months
Hibernate has a new website
by Emmanuel Bernard
http://hibernate.org has been completely revamped.
The entire team has been working on it for a long time. I am personally
very happy to see this puppy out.
Our goals were:
* to help newcomers understand what each Hibernate project is about and why it matters
* to help regular / advanced users to find what they are looking for quickly
* to give higher visibility to what mattered most
* to clarify the fact that Hibernate is an umbrella of (awesome) projects
The infrastructure is also much easier and flexible (you can even contribute
pull-requests to fix typos or improve the site). You will see additional
improvements over the coming months. Especially around better integrated
documentation.
Let us know what you think and of any glitch you might see.
http://hibernate.org
Emmanuel
PS: the DNS propagation might take a little while
12 years, 4 months
