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 <sa...@hibernate.org>: > On 5 May 2015 at 12:39, Gunnar Morling <gun...@hibernate.org> wrote: > > Hi, > > > > Answers inline. > > > > --Gunnar > > > > 2015-05-05 13:04 GMT+02:00 Sanne Grinovero <sa...@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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
