[hibernate-dev] Which versions of the application server should the Hibernate OGM modules support

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.

--Gunnar

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
> 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).
>
> 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
> 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.
>
> 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
> 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).
>
> 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
> 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).
>
> 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
> 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.
>
> +1 Let's align with ORM, not the containers. Especially as the old
> version works in the newer containers.
>
> Thanks,
> Sanne
>