[weld-issues] [JBoss JIRA] (WELD-935) Do not deploy shaded jars like weld-servlet (as a bad replacement for weld-servlet-core) because they break dependency conflict resolution and introduce classpath issues

Thu May 31 01:36:17 EDT 2012

    [ https://issues.jboss.org/browse/WELD-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12697370#comment-12697370 ] 

Bob Obringer edited comment on WELD-935 at 5/31/12 1:35 AM:
------------------------------------------------------------

It appears that this is still an issue in Weld 2.0.0.Alpha2.

Our development/build process is so tied to maven that this issue makes weld a non-starter.  Is there ANY way to use Maven to include a dependency on Weld without breaking our existing SLF4J implementation?

We've also got other dependencies on javassist.

Seems that for those of us who don't include our dependencies by hand, we really need a way to include weld-servlet in our projects.

      was (Author: bobringer):
    It appears that this is still an issue in Weld 2.0.0.Alpha2.

Our development/build process is so tied to maven that this issue makes weld a non-starter.  Is there ANY way to use Maven to include a dependency on Weld without breaking our existing SLF4J implementation?

> Do not deploy shaded jars like weld-servlet (as a bad replacement for weld-servlet-core) because they break dependency conflict resolution and introduce classpath issues
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WELD-935
>                 URL: https://issues.jboss.org/browse/WELD-935
>             Project: Weld
>          Issue Type: Bug
>    Affects Versions: 1.1.1.Final
>            Reporter: Geoffrey De Smet
>
> Shading = repackaging a dependency class inside your own jar (instead of depending on the jar of that class).
> I've just spend quite some time trying to find such a classpath issue, which manifested it self as "NoSuchMethodError on slf4j LocationAwareLogger.log(...)"
> It turns out the weld-servlet jar was shading some of the slf4j classes.
> Shading is evil. Here's why:
> - It breaks maven/gradle/buildr/ivy dependency conflict resolution. If guvnor uses slf4j 1.6 and weld-servlet; and weld-servlet shades slf4J 1.5; maven will not detect a slf4j version conflict and will therefor have no chance to put only 1 version of slf4J in the classpath. As a result, there's no telling which slf4J version will be used (the first in the classpath, but that is very unstable)
> - It distorts ANT's classpath: putting the weld-servlet jar (with slf4J 1.5) in your classpath can effectively turn the explicit slf4j-1.6.0.jar in your classpath into dead code or combine it with binary incompatibly slf4j extensions such as xstream-for-slf4j-1.6.0.jar (fictive example).
> - Because the slf4j classes are actually in the weld-servlet jar, they cause bloat: the user might have already downloaded the real slf4j jar.
> - Most importantly, because the (Red Hat and other) guys who create RPM's out of our jars say so. See slide 13 of this Fosdem presentation: http://sochotni.fedorapeople.org/fosdem2011-sochotnicky.pdf (video : http://ia600608.us.archive.org/16/items/fosdem_2011_free_java_guide_to_packaging_for_developers/20110205-fosdem11-guide_to_packaging.ogg)
> Summary: shading will cause grief for your users. Why subject your users to grief? In this case, don't give them a good and a bad choice, only give them a good choice.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira