I've installed a preview build of JDK8 on ci.hibernate.org, and
created jobs for:
Gunnar is adding Validator.
There are some exceptions that we should investigate; one of them is
Animal Sniffer breaks.
I've debugged it and came to the conclusion it doesn't work because it
uses ASM to actually inspect the bytecode, and it should use ASM 5 to
be able to parse the bytecode produced by the Java8 build.
Ideally we should build with Java7 (since we'll be releasing with
Java7) and then run the tests only with Java8, but having concluded
that it's not a JDK8 regression but simply a limitation of the plugin
being outdated, I've opted for running these builds with:
We should look at the other failures now: we could implement
workarounds in our code, but it's of higher value to identify
potential regressions in the JDK and report these quickly: that would
allow people to move on to Java8 even when they are stuck with an
older release of our libraries.
Gitter is a new service aiming to replace IRC, and specifically meant
for OSS projects team working with Github.
I've got an invitation to participate to the beta, and got it setup
for these chatrooms (open to the public):
I've setup integration from Jenkins and Github so we should get
notifications in the chatroom about commits, PRs, reviews and build
jobs (totally untested so far)
Shall we give it a try?
Some features which I'm liking:
- it provides a per-repository chatroom and an organization wide chatroom
- history is always available, cloud stored and full-text searchable.
so we can jump to one device to the next or stay offline and catch up
- has native clients for Mac, iOS, Android (but I'm using the webpage
which works great and has desktop notifications via Chrome)
- no new accounts: you login via GitHub, so your permissions on the
chatroom are inherited from your permissions on the respective
- people join following just the links above.. very low hassle for newcomers!
I'll be there and on IRC as well in the foreseeable future.
Just a quicks heads up about some work Gail and I will be doing in the
ORM repo today. Mainly the time has come to transition (back) to 5.0
development. We have submitted our passing JPA 2.1 TCK results to
Oracle, but are still awaiting response back from them; once we get
approval from them, I will be releasing 4.3 Final.
So the following concrete things will happen in the next few days:
1) I will create a 4.3 branch from the 4.3.0.CR2 tag. I will use this
to re-tag 4.3.0.CR2 as-is as 4.3.0.Final (thanks Gail for the idea!).
After I get 4.3 Final released I will port all the changes between CR2
and master HEAD to this new 4.3 branch.
2) Gail will work on getting the metamodel branch rebased against
current master. After the steps above are complete, we will (ff) merge
that work to master and push upstream. At that point master will
represent 5.0 development. We will drop metamodel branch.
Let us know any questions/concerns...
In the context of embedded associations for CouchDB , I'm working on
support for configuring the association storage mode using our new option
system . I can see the following "axes" of configuration here:
* via annotation
- on an association property
- on a type
* via the option API
- on an association property
- on a type
- on the global level
* via a configuration property as given via OgmConfiguration,
* on super-types
- via annotations or API
- on the property or entity level
I'm looking now for a sensible and comprehensible algorithm for taking
these sources of configuration into account and determining the effective
setting for a given association. This could be one way:
1) check API
a) look for a setting given via the programmatic API for the given
b) if the property is not configured, look for a setting given for the
c) if the entity itself is not configured, repeat a) and b) iteratively
on super-types if present
d) if no type from the hierarchy is configured look for the global setting
2) check annotations
if no configuration could be found in 1), do the same for annotations,
a) look for configuration on the given property
b) look for configuration on the given entity
c) repeat a) and b) iteratively on super-types if present
3) take default value given via OgmConfiguration/persistence.xml etc.
This algorithm ensures that:
* API configuration always takes precedence over annotation configuration;
e.g. if a super-type is configured via the API or the setting is given on
the API global level, any annotations are ignored
* "More local" configuration takes precedence; i.e. a type's own
configuration wins over configuration from super-types, property-level
configuration wins over entity-level configuration
Note that any setting given via OgmConfiguration/persistence.xml would be
handled as last fallback option, i.e. any configuration given via
annotations or the API would take precedence over that. I first didn't like
that but I came to think it makes sense, if the property name conveys that
semantics, e.g. "defaultAssociationStorageMode".
Any other thoughts or alternative approaches around this?
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?
Red Hat, Hibernate ORM