[hibernate-dev] Slots of the OGM modules

[Gunnar Morling]

I wouldn't go as far and call it "very wrong"; There just hasn't been any
demand for running several OGM versions in parallel, so no one cared for
enabling such scenarios.

That said, 5.0 seems like a good time to do so as I can see some people
might want to use 4.2 and 5 in parallel, so +1 for doing it.

> Not least, we seem to have various properties which allow each module
to be released with a different slot id

I don't think the purpose of these props has been so much releasing with
different ids, but more maintaining the slot ids in one place (e.g.
"hibernate.ogm.mongodb.module.slot" is referenced twice, once in module.xml
and once in dist.xml). If you see room for simplifications, go for it; But
I wouldn't spend huge amounts of time on it, given this is working.






2016-03-29 13:19 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> I just noticed something which seems very wrong with the OGM modules,
> although I guess I'm correcting a mistake of a younger self :)
>
> The various modules of Hibernate OGM use the "main" slot, rather than
> using the version of the project.
> This makes it impossible for people to deploy different versions of
> OGM, or worse it makes it possible for people to unintentionally
> overwrite some parts of it with a different version.
>
> In Hibernate Search we learned long ago - probably thanks to the
> experience of the complex integration with both WildFly and Infinispan
> and others - that it's much safer to provide modules using the slot
> name "major.minor", i.e. we'd have "5.0" for the upcoming OGM release
> 5.0.0.Final.
>
> Even better, we should publish the public modules (the ones the end
> users are expected to mention in their configuration files / metadata)
> with this scheme, but these to be aliases which resolve to the
> specific version: that allows people to be decoupled from the micro
> updates, yet be able to override this in case of need and still
> require a specific micro.
>
> Not least, we seem to have various properties which allow each module
> to be released with a different slot id (i.e. couchdb and mongodb
> modules could use a different scheme) and I currently can't think of
> when this is useful, I'd suggest we get rid of that and make it all a
> bit simpler.
>
> Since I'm cleaning up other modules changes now I'd like to do this right
> now?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>