[hibernate-dev] Which versions of the application server should the Hibernate OGM modules support
gunnar at hibernate.org
Tue May 5 08:30:57 EDT 2015
Had a quick chat with Sanne on IRC :)
The reason it seemingly works with WF 8 + ORM 4.3.7 is that the bug I have
been talking about (HHH-9451) is not triggered by any of the integration
tests running on WF but only by a unit test in the MongoDB module.
Thus we agreed to not go through the hazzle of updating the WF 8 module ZIP
and create one for WF 9 instead. We will stick to the JBL version used by
ORM, so users could still create their own WF 8 module ZIP if needed.
Wrt. to the ZIP, could this be provided alternatively in form of a "feature
pack" instead? I have been hearing about it several times, but I don't
know really whether that's possible already and what it would take to do it.
2015-05-05 14:09 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> On 5 May 2015 at 12:39, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi,
> > Answers inline.
> > --Gunnar
> > 2015-05-05 13:04 GMT+02:00 Sanne Grinovero <sanne at 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
> > is only a single ZIP targeting WF, having the major revision in their
> > 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
> > 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
> > have to be updated (including ORM).
> Likely, as I said. I proposed to volunteer for this but only if we
> agree we want that.
> I guess you're both voting for it?
> >> # 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
> > has been addressed, such job could (and should) easily be
> > 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
> > preference is to test one set up during the default build (i.e. also
> > when running "mvn clean install") and run all others on CI. We do the
> > e.g. for JDK versions (8, 9) and MongoDB providers (actual MongoDB,
> > Running all these (and possibly combinations thereof) as part of each
> > 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
> > PR for updating the WF8 ZIP, that'd be great of course and I would be all
> > for integrating it.
> The WF8 updates are working fine today, there is no need for a PR.
> My question is rather if we should aim at keeping them working, or
> throw out and replace with WF9.
> It's also related to how you do integration tests.
> I'll code the module to produce both, we can later decide if you want
> these to trigger by a non-default profile or have options to disable
> them locally.
> >> 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
> > 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
> > have just removed this. Now we could un-do that, but I'd prefer to move
> > actually (if not only to benefit from other bug fixes in 4.3.9).
> Tests seem to work fine, while it's linked to the default module or
> ORM (v. 4.3.7).
> What am I missing?
> In this scope we're not after the ORM bugfixes.
> >> 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
> > keep it, the integration test module would need to get another profile,
> > we can run tests against WF 8 and 9 (on CI).
> Ok, but could you please open JIRAs to point out what's wrong with the
> WF8 modules?
> >> # 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
> > of matching dependencies. But I just noticed that there is an
> > already: ORM 4.3.9 still is on 3.1.3, whereas WF 9 has 3.2.1. So this
> > wait a bit indeed IMO.
> +1 Let's align with ORM, not the containers. Especially as the old
> version works in the newer containers.
More information about the hibernate-dev