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

Scott Marlow smarlow at redhat.com
Thu Jan 15 10:54:24 EST 2015


On 01/15/2015 09:49 AM, Emmanuel Bernard wrote:
>
>> On 15 Jan 2015, at 14:56, Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>> When we talked at the f2f, I said that we would do major.minor, I think
>> that is the summary notes from the discussion.
>>
>> If we were to reverse the definitions, so that org.hibernate:main is an
>> alias for a specific version of ORM (whether its using major.minor or
>> major.minor.micro, it makes no difference to me) and that offers the
>> advantages that your thinking of.
>
> I think what Sanne propose is what he and I had in mind when we
> discussed at the f2f. I think it makes a bit more sense.

I think that this is some sort of minimal/maximal regular expressing 
matching thing.

When we discussed this at the f2f meeting, I was thinking of the minimal 
way to do what you wanted and thought we were in sync.  Now, I 
understand the additional part of what you wanted (more of a maximal 
match).   :)

I think the simple change, is to invert the modules, like suggested. 
Such that org.hibernate:main is an alias that points to a real module.

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.

One question is how will the different actual "4.3.micro" modules be 
created?  Would external tools automate that or the user manually create 
them (copy all of the Hibernate jars in, setup a module.xml and 
reference needed dependencies)?

Scott


More information about the hibernate-dev mailing list