On 8 October 2012 17:07, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
On Mon, Oct 8, 2012 at 3:34 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> I'll leave it to the gradle gurus on the team to say how to fix that,
> but I'm surprised that Maven suggests both dependencies, that should
> never be the case.
It doesn't include both, of course. But both dependencies are present
Ah understood now. thanks.
We often have various dependencies with different versions so it's not
a real problem. The problem here is that hibernate-entity-manager
requires 2 versions of the same dependency. If I exclude it, I have to
maintain the version by hand, which I'm not very fond of, especially
for such technical dependencies.
With Emmanuel's solution, you'll have to release a new version of
hibernate-commons-annotations each time you upgrade jboss-logging in
hibernate-entity-manager. That's why I thought excluding the
jboss-logging dependency coming from hibernate-commons-annotations in
hibernate-entity-manager might be a better idea.
It's not a critical problem at all but I think it's worth it to have a
clean dependency tree for components as widely used as Hibernate.
Right, we'll clean it up, still.. I think any project having more than
one dependency risks collisions of this type, it's just the nature of
dependencies: as you say without careful exclusions we'll have to
release a new one each time - which implies releasing a new
entitymanager as well ;)
The fact is that if you use the maven-enforcer-plugin with the
dependency convergence rule (
), just adding the hibernate-entity-manager dependency to any project
breaks this rule.
Looks like we could use that trick to define some sort of "canary"
project in continuous integration to verify these issues. I fear
however it would complain very often: the different projects are
maintained in different repositories and have a different life-cycle
to allow some degree of flexibility on release dates and dependency
versions. Otherwise they would all be sub modules of the same
Still, better to know about it: if someone volunteers to define such a
module I'll add it to Jenkins for regular builds. Might be a good idea
anyway to verify Gradle is producing proper pom files ;-)