On 5 May 2015 at 12:33, Davide D'Alto <daltodav...@gmail.com> wrote: >> # 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.
That's what I refer to in the next paragraph. > 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? Good point, that reminds me why we had it as a profile. Still WF8 && WF9 could both be built w/o adding an additional repository. I'll see if that can all be automated. Thanks, Sanne > > Davide > > > > > On Tue, May 5, 2015 at 12:04 PM, Sanne Grinovero <sa...@hibernate.org> > 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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
