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

Bob Obringer commented on WELD-935:
-----------------------------------

It appears that this is still an issue in Weld 2.0.0.Alpha2.
                
> 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

        
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues

Reply via email to