[hibernate-dev] Repackaging dependencies with Hibernate
sanne at hibernate.org
Tue Feb 6 08:29:22 EST 2018
Repackaging, shading, etc.. are all a nightmare for supporting the
library down the road so we'd strongly prefer against doing such
For users it's a nightmare as well when it comes to debug things, as
it breaks all tools such as having your IDE download the matching
sources for stacktraces, etc..
FWIW, we had a similar discussion on Infinispan some years ago, with
some people really wanting to hide some dependencies into shaded
modules to make project setup simpler. I lost that argument: shading
was done, and later we had so much pain that the decision was now
finally reverted. That team learned the lesson and will never use
I hate to sound biased, but when you run an application in WildFly you
don't have this issue, as these "internal dependencies" don't pollute
the application's classpath: it's not a problem at all if the user
pulls in a different version of ANTLR.
I don't know much about WebLogic, but it really should be able to do
the same as any app server is required to provide some similar feature
- perhaps in the WebLogic case it's not nicely exposed as a feature
people can use, but that's their problem to not expose useful stuff :)
Regarding non technical issues: I'm not aware of a licensing issue,
not blocking at least in the case of ANTLR although we'd likely need
to add some clarification notes in the readme and licensing notes, in
case we really wanted to do such a thing ..
I'm glad others - e.g. Spring - repackage their dependencies, so
that's less likely to conflict with our dependencies :P
On 6 February 2018 at 12:42, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> This Hibernate forum question provides a good point:
> Frameworks like EclipseLink and Spring (
> https://twitter.com/starbuxman/status/960854907854249986 ) repackage
> dependencies to avoid the issue when the user needs a different library
> version (ANTLR 3.3) in their Classpath.
> Is it possible to do so for Hibernate ORM? Is there any license issues that
> would prevent doing it?
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
More information about the hibernate-dev