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

[Sanne Grinovero]

On 5 May 2015 at 12:33, Davide D'Alto <daltodavide at 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 <sanne at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>