[hibernate-dev] Hibernate OGM split in modules, ready for new integrations!
hardy at hibernate.org
Wed Dec 7 08:16:59 EST 2011
for what it's worth - there are so called advanced reactor build options:
However, I think they are fundamentally broken. In your case you could do something like
mvn install -pl hibernate-ogm-ehcache -am hibernate-ogm-core
On Dec 7, 2011, at 1:47 PM, Sanne Grinovero wrote:
> Hi Alex,
> I'm not sure if there is a way in Maven to have it find the other
> modules automagically; if there is I'm not aware of it: I generally
> expect projects to be built from the root, so what you did is the same
> approach I usually take.
> You can then build the module only to save some time, but it's up to
> you to know that you don't need to install a new snapshot of the older
> modules, or your tests will run with the previous installation, so
> it's only safe if you don't make any change outside of your module
> (which is great, but feel free to suggest changes in other areas).
> Anyway for the record we all use Maven 3.0.3, I don't think anybody
> tests the build on older Maven versions.
> Regarding the formatting, please do use the Hibernate Core style, when
> you see something formatted differently that was a mistake.
> On 6 December 2011 21:45, Alex Snaps <alex.snaps at gmail.com> wrote:
>> Hey Sanne,
>> I started creating the layout for the hibernate-ogm-ehcache module.
>> Now I stumbled on something, given I'm no maven expert, I think might
>> not be quite right:
>> from the parent project, it couldn't resolve the dependency to
>> hibernate-ogm-core, so I first had to install that from the
>> ./hibernate-ogm-core module, so I could build from the root.
>> I think this might not be what is wanted though ... Is there a reason
>> for that ? Or is this some weirdness I experience because I used mvn2
>> still ?
>> Otherwise I started the module on my fork on github and will work to
>> get something passing tests as soon as possible.
>> Thanks a lot for all these changes!
>> PS: Also, I started using my Hibernate-core code style, but look like
>> this might use another, right ?
>> On Sun, Dec 4, 2011 at 7:21 PM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> Hi Greg,
>>> we've implemented all changes in Hibernate OGM which we discussed at
>>> Devoxx to make it easier for you to create a new module and get
>>> started experimenting with an EHCache integration.
>>> Actually to proof myself correct I've already created a new module,
>>> and removed Infinispan from the main module relegating it in it's own
>>> extension; so while in the main pom and possibly in some comments and
>>> documentation Infinispan might still be mentioned as the "main"
>>> supported engine, it's not the case anymore as far as the
>>> implementation concerns: the tests of the core module are now using a
>>> "spiced" ConcurrentHashMap instead and we'll improve on the docs too
>>> as soon as we actually have an alternative. I hope this will let you
>>> get started quickly, basically you only have to look into the
>>> Infinispan module and think how to best implement the 6 trivial
>>> The structure of the testsuite might need some warnings: since the
>>> tests verify the functionality via the user API, we actually want to
>>> re-run all the tests on each database. That's what Hibernate Core
>>> always did, via a couple of properties it switches the JDBC driver and
>>> connection details, just one class cares for the dialect which
>>> encapsulates the database specifics; but most code is well tested
>>> using a single database, so by default the testsuite runs H2 only,
>>> while Jenkins re-runs the full testsuite on all supported databases.
>>> In the case of Hibernate OGM, the code which we actually want to test
>>> is the integration with each database, so running tests on only one of
>>> them is not really an option.
>>> To re-run the same testsuite multiple times, and to keep all the
>>> database specific code and dependencies in different modules, we're
>>> hacking a bit around Maven by packaging the testsuite from the main
>>> module and referring to the same tests again in each module.
>>> Basically I'd suggest to have a look at how the
>>> hibernate-ogm-infinispan module reuses the test code from
>>> hibernate-ogm-core; most of the magic is triggered by the
>>> maven-dependency-plugin in the parent pom.xml and the
>>> org.hibernate.ogm.test.utils.InfinispanTestHelper in the test sources.
>>> Of course you can add additional EHCache tests as you like in the new
>>> hibernate-ogm-ehcache module, but I'd suggest to reuse all tests from
>>> We can certainly polish this approach if it doesn't proof sound in
>>> practice, but I hope it's a good way to get started with it. It should
>>> provide some convergence of features across "databases"; if some
>>> feature can really not be implemented we can introduce flags to
>>> disable groups of tests in specific modules; for now there exists one
>>> such flag which disables JTA integration  : I'm using it with the
>>> Map implementation as I didn't implement transactional support on it.
>>> In theory you could introduce more such flags if you really need to
>>> disable some other tests, but that would be the least desirable option
>>> as we hope to provide a consistent behaviour across different backing
>>> databases as much as possible.
>>> The basic build information can be found here:
>>> For any question, we're looking forward to help you!
>>> 1 - org.hibernate.ogm.test.utils.TestableGridDialect.backendSupportsTransactions()
>> Alex Snaps <alex.snaps at gmail.com>
>> Senior Software Engineer - Terracotta
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
More information about the hibernate-dev