[hibernate-dev] Hibernate ORM modules published as major.minor and an alias for main

[Emmanuel Bernard]

> On 16 Jan 2015, at 13:58, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> On 15 January 2015 at 16:01, Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>> wrote:
>> 
>> On 15 Jan 2015, at 16:54, Scott Marlow <smarlow at redhat.com> wrote:
>> 
>> 
>> The part that I am unsure about is including the micro version in the module
>> path, which means that every release of WildFly that includes an upgraded
>> Hibernate, will likely have the jars in a different path (could be a pain
>> for any configuration settings that point to the Hibernate jars).
>> 
>> The actual module path would also move around a lot in git, which is
>> annoying but I have no real complaints about that.
>> 
>> 
>> On that I am neutral. I remember Sanne advocated this but I forgot the
>> rational nor if I was convinced ;)
> 
> Uhm it's annoying that the file would move in git indeed. But is that
> a requirement of the modules system or is that a convention which we
> could challenge/refine?
> 
> For technical reasons it's obviously better to be able to pick a
> specific version than not being able to; for example OGM requires a
> specific version of ORM, and "4.3" is not good enough to make sure
> we're using the right one. The current solution is working because
> we're building against a specific Wildfly / EAP version and build the
> modules taking advantage of our knowledge of the specific versions
> we'll encounter in there, but it's getting more complex quickly.
> 
> I understand that some people will be happy enough to state they
> depend on "ORM 4.3" rather than "ORM 4.2" and having you drop-in micro
> updates as convenient. In *theory* we promise full drop-in backwards
> compatibility on the micro version so we should be able to expect a
> user to just need to specify the major.minor, but there's the
> possibility of unintentionally breaking this promise (a bug) or - as
> historical facts - either OGM or Search needing a specific version.
> 
> Sometimes it's just more practical for us to break our "internal
> contracts" even in a micro release, to move on timely; in this case we
> require a specific micro of ORM even though the exposed contract to
> end users and other integrators is still backwards compatible.
> 
> So I think it would be better to have both module representations
> (major.minor and major.minor.micro): we'd consider the .micro
> variation as something people shouldn't use unless they have a
> specific need.. but it's good to be able to use it when such a
> specific need arises.
> Still if that's too inconvenient, just having the major.minor would be
> an improvement on current state :)
> 
> No other project raised such needs on the WildFly mailing list?
> (except Infinispan, which is in our same needs)

So let’s assume that WF 8.1.0 pushes ORM 4.3.4 and WF 8.1.1 pushes ORM 4.3.6.
And let’s assume that OGM 4.1.0 uses ORM 4.3.4 and OGM 4.1.1 uses ORM 4.3.6 (due to the issues you describe above).

If you put the major.minor.micro in WF with aliases for major.minor and main, does that really help OGM?
1. if WF 8.1.1 does not keep ORM 4.3.4 around, then I would say no. As OGM module provider, you still need to know that a given WF version has the right version or not.
2. if WF 8.1.1 does keep the old ORM versions around (i.e. ship 4.3.4 and 4.3.6), then still OGM does not know if the exact version of ORM is included.

The only solution I can think of is for OGM to also bundle the minimal ORM major.minor.micro it needs and have a way to ask the module system to use the most recent between that one and the WF one. I don’t think the module system offers than and I think they are against version range for a lot of reasons.

So turning the table, how does your solution solve or improve the problem Sanne?