1:39 p.m.
Hi,
Answers inline.
--Gunnar
2015-05-05 13:04 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
Hello all,
I actually have multiple questions on the subject.
# Module name
The Maven artifact id of the modules we're producing for WildFly 8 is
aptly named "org.hibernate.ogm:hibernate-ogm-modules-wildfly8".
I still think that's a good choice, as deploying modules is an
operation which is strictly coupled to the application server version.
I'm merly reminding this point as it suggests we *could* if - we want
to - easily produce modules for multiple application server versions.
Yes, this was exactly the idea behind this naming: being able to provide
modules for different baseline versions, WF 8, 9 etc. Whether we actually
do create more than one at a given time is another question IMO. Also if
there is only a single ZIP targeting WF, having the major revision in their
still communicates very clearly the targeted baseline.
# EAP versions
We're also producing modules for JBoss EAP6, but AFAIR these need some
love and I'm not sure if it's worth the effort - it might not need to
much work and I'm happy to look at it if you want to, but in case we
fix it these should have proper integration tests [next]:
At this point the EAP6 module ZIP is quite outdated, I don't think it will
work as is. Maybe it's not a bad idea to update it now that 6.4 is out? I
am not sure about the effort it'd need, but I expect quite a few modules
would have to be updated (including ORM).
# Integration tests of these modules
The current solution is that the integration tests are run with a
profile selection: so we choose upfront in the build if we want to
test the wildfly8 modules or the eap6 modules.
Are we still happy with this setup? I don't see a CI job which
verifies the EAP6 modules and I doubt you're all running the tests
twice.
Should we:
A) add the CI job to verify the other profiles (EAP6 and others as needed)
B) change approach and have the tests re-run for any build
C) remove the EAP6 modules
My vote goes for B, even though it will make test runs take a bit
longer. To improve speed we can do other things - to be discussed
separately so I'd hope we don't give the execution speed too much
weight for the above choice.
There is no CI job (anymore) as the EAP module ZIP is outdated :) Once that
has been addressed, such job could (and should) easily be re-instantiated,
so my vote would go for A).
Wrt. B), is this to say that you'd run the tests for WF *and* EAP as part
of local builds, too? If so, I am no fan of it. Build time is an issue, so
my preference is to test one set up during the default build (i.e. also
locally when running "mvn clean install") and run all others on CI. We do
the same e.g. for JDK versions (8, 9) and MongoDB providers (actual
MongoDB, Fongo). Running all these (and possibly combinations thereof) as
part of each build just takes too long.
# WildFly 8 vs WildFly 9
At the last meeting we agreed to support WildFly 9. We didn't decide
at what cost towards WF8 users: should we drop the WF8 modules?
It was my understanding that we would not put effort into updating the
modules for WF8 but rather focus on WF9. If there was a community-provided
PR for updating the WF8 ZIP, that'd be great of course and I would be all
for integrating it.
I think I'm ok with dropping the older modules, however since we
have
chosen for a module name which includes the version, it's pretty easy
for us to keep the WF8 modules around for now, and it's equally easy
to remove them from the project in future when we don't want to do
that anymore.
The name is one thing, but it also needs to be maintained. As said on JIRA,
the WF8 ZIP would at least have to be updated to pull in ORM 4.3.9. OGM
depends on a bugfix provided in that version. We used to have a local
work-around for this (so we could work with 4.3.7 coming with WF 8), but we
have just removed this. Now we could un-do that, but I'd prefer to move on
actually (if not only to benefit from other bug fixes in 4.3.9).
Documentation (user complexity) wise the instructions would be
identical so it's not a big burden to explain - one would just need to
pick the right set of modules.
I would prefer to keep the WF8 modules around for a little bit, but
only if we agree on an integration testing strategy which is able to
cover all the modules we build.
See above, the WF8 ZIP would need at least one update. Should we decide to
keep it, the integration test module would need to get another profile, so
we can run tests against WF 8 and 9 (on CI).
# JBoss Logger version
As a reminder, there's an update for JBoss Logger which - if applied -
will make it harder for OGM to work on WF8. Gunnar is making some
interesting suggestions to work around this on OGM-803 but let's see
first if
- we really want to keep WF8
- cant we not simply wait to update, I don't see why we should seel
trouble by upgrading this component now.
My reasoning for upgrading was that I prefer to work with a consistent set
of matching dependencies. But I just noticed that there is an inconsistency
already: ORM 4.3.9 still is on 3.1.3, whereas WF 9 has 3.2.1. So this could
wait a bit indeed IMO.
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev