Nothing Gradle specific here. Not following why you say that. He is
talking about projects including hibernate-entitymanager, which I assume
is using Maven since I believe every Hibernate sub-project is still
using Maven to build (correct me if I am wrong there).
That said, this is in fact exactly what Maven does. It just blindly
includes all versions. At least thats what it did in Maven 2. I have
not played much with Maven 3. You project, the one including
hibernate-entitymanager, controls this through <dependencyManagement/>
to name the singularized version of a dependency to pull in even across
transitive deps. Again, thats how it used to work in Maven 2, and I
have heard of no changes in that regard for Maven 3.
On 10/08/2012 08:34 AM, Sanne Grinovero 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.
As a workaround, if you define an explicit dependency on jboss-logging
in your <dependencyManagement> section you should be able to avoid any
I always specify dependency versions explicitly in this form (in our
projects using Maven) so that might explain why we never noticed this
On 8 October 2012 13:49, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
> I don't know what is your policy about the dependency management but,
> currently, when you include hibernate-entity-manager in the pom of an
> application, it comes with dependencies to 3.1.0.Final and 3.1.0.CR2.
> The problem is that hibernate-commons-annotations-4.0.1.Final requires
> 3.1.0.CR2 of jboss-logging. See:
> I was wondering if it was possible to add an exclusion to the
> hibernate-entity-manager pom.xml (or the Gradle equivalent) to not
> drag the jboss-logging dependency of hibernate-commons-annotations so
> that from the outside the dependencies of hibernate-entity-manager are
> Thanks for your feedback.
> hibernate-dev mailing list
hibernate-dev mailing list