[
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
_______________________________________________
weld-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/weld-issues
