Small change to the ORM Travis configuration
by Guillaume Smet
Hi,
The Travis cache behaves this way:
- try to get a cache specific to the PR
- then try to get a cache for master
- if none found, start without cache
The ORM Travis build was configured to not build the branches so master was
never build thus each PR starts with an empty cache (but subsequent pushes
to the same PR will use the PR cache).
I enabled the build for branches (Settings > Build pushed branches) so that
you have a cache for master. This should speed up the builds significantly.
--
Guillaume
6 years, 2 months
Releases and CI setup
by Guillaume Smet
Hi,
So, as expected, I'm not very happy with the new CI setup when doing
releases.
The issue is that each commit to ORM triggers at least 5 jobs (5.0, 5.1,
5,2, master-h2, master-check) which takes all the slave bandwidth we have.
Note that I'm talking of ORM because it's where the issue is the most
prominent but I'm pretty sure I would have the same issue with HV,
considering we now have quite a few maintenance branches, except that the
HV builds are faster.
So I would say:
- either we fix the issue we have with all the branches being tested for
each commit that we discussed numerous times
- or we need a mechanism to start specific slaves for releases - but I'm
not sure it's fast enough tbh
Because it's really annoying. Especially when you have to run your release
job 3 times in a row due to SF.net issues...
Releasing is already a tedious process, let's not make it even more tedious.
(yeah I know it's not the first time I complain about it but it's really
worse than it was before)
--
Guillaume
6 years, 2 months
HSEARCH-3000 Pick Jigsaw Automatic Module names for all published modules
by Sanne Grinovero
Picking automatic module names for Hibernate Search isn't going to be
straight-forward as our two main jars (hibernate-search-engine &
hibernate-search-orm) suffer from split package among them.
We can't really fix the split package problem without breaking all
users, so if we want to consider that, we can debate it but that will
need to happen at another round as we're doing a minor release, so
let's focus on:
# Which names to pick
# Should we pick the names at all
# Which modules should have a name
For a great background on the possible strategies and pitfalls I
recommend reading Stephen Colebourne's blog on this subject [1].
He persuaded me there are good reasons to use the "reverse DNS, the
top level package", however since we have the split package problem we
can't simply go with that.
Still, we can respect the principles he recommends with a small
variation. It's fair to assume that the `org.hibernate.search` prefix
is "ours"; since the nature of the suggestion is focused on making
sure there are no misunderstandings in the community about which names
you can choose - as there is no central authority making sure module
names aren't clashing - we should be fine within Hibernate projects
with any `org.hibernate.X` prefix, as long as we coordinate and reach
an agreement on this list.
So, I propose we use:
Engine module:
- org.hibernate.search.engine
ORM integration module:
- org.hibernate.search.orm
JGroups, JMS backends:
[ no automatic module name ? Excepting some "guidelines" in the JMS
module, these are not public API so nobody would benefit from it -
also we think we might want to phase out the name "backend" in the
future ]
Elasticsearch integration module [hibernate-search-elasticsearch.jar]:
- org.hibernate.search.elasticsearch
Elasticsearch / AWS security integration:
[ no automatic module name: no public API ]
Serialization / Avro
[ no automatic module name: no public API ]
WDYT?
We could also pick names for the ones which I've listed as "no public
API" but I see no point: as we're only assigning an "Automatic Module
Name" we won't be able to explicitly state that the other modules
depend on these. So nobody will use them, and things are a bit in flux
anyway in this area because of Hibernate Search 6 plans.
Another optional altogether: since we have split packages which we'll
have to resolve before we can actually transform these into fully
fledged modules, I think an acceptable position is also to say we
won't be publishing any automatic module name yet. Personally I'm
inclined to go with the names suggested above, at least some others
can start making baby steps, even if it's not all there.
# What I don't like:
For one, that the typical application will need to import both
`org.hibernate.search.engine` and `org.hibernate.search.orm`, and
likely more as well (e.g. Elasticsearch API, Lucene API module is
coming, ..).
Maybe similar to BOM's today we could publish a module which
statically imports multiple of these, that could be nicer to use but
we risk needing to publish (and document) one for each of a selection
of combinations. So let's not start with such things yet.
Thanks,
Sanne
[1] http://blog.joda.org/2017/05/java-se-9-jpms-automatic-modules.html
6 years, 2 months
Depending on JAXB / JDK11 compatibility
by Sanne Grinovero
With JAXB being part of the JDK in Java 8, Hibernate ORM doesn't list
it as a runtime dependency.
Java 9 users have been suggested to use the JVM option "--add-modules
java.xml.bind" to avoid the JVM hiding the JAXB library from
classpath.
With Java 11 the java.xml.bind is no longer available; what should we
suggest to users?
Should we list it as an explicit dependency in the released pom files?
Thanks,
Sanne
6 years, 2 months