[hibernate-dev] hibernate-commons-annotations dependencies

[Sanne Grinovero]

On 8 October 2012 17:07, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi Sanne,
>
> On Mon, Oct 8, 2012 at 3:34 PM, Sanne Grinovero <sanne at 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
> and exposed.

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 (
> http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html
> ), 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
"Hibernate" project.

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 ;-)

Sanne

>
> --
> Guillaume