# EAP versions We're also producing modules for JBoss EAP6, but AFAIR these need some ove 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]:

# Integration tests of these modules ... B) change approach and have the tests re-run for any build

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. # 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]: # 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. # 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? 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. 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. # 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. Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

> # EAP versions > > We're also producing modules for JBoss EAP6, but AFAIR these need some > ove 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]: I think we already have integration tests in place, we are not running them at the moment because the module for eap needs some love.

There is a profile in the pom of hibernate-ogm-integrationtest. If you enable the profile the test are executed (mvn -Peap). It would probabaly be easier to maintain update if we move the tests in different modules, the speed of the build can still be managed via profile. I think the reason it wasn't executed by default was mainly because there was some complexity when downloading EAP from the repository for new contributors. I'm not sure if this is still the case > # Integration tests of these modules > ... > B) change approach and have the tests re-run for any build This is the solution I prefer although it might slow down the build. Is it possible for a new contributor to dowload EAP from a maven repository or does it requires a special repository and related permissions?

Davide On Tue, May 5, 2015 at 12:04 PM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > > 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. > > # 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]: > > # 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. > > # 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? > 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. > > 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. > > # 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. > > Sanne > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 5 May 2015 at 12:39, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > Hi, > > Answers inline. > > --Gunnar > > 2015-05-05 13:04 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org&gt;: >> >> 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