On Dec 4, 2012, at 8:09 PM, Sergiu Dumitriu <[email protected]> wrote:
> On 12/04/2012 01:10 PM, Vincent Massol wrote: >> Hi devs, >> >> I'd like to propose that we stop shading Rendering Standalone. The reasons >> are: >> >> 1) It's far from perfect. For example we have at least 3 libs we cannot >> shade: >> >> <!-- We don't relocate the following packages since they cause >> runtime issues: >> - javax.xml >> - org.w3c >> - org.apache.xerces >> --> >> >> >> 2) As we added some libs to our deps we forgot to relocate them so right now >> we don't shade (to cite a few): com.steadystate.css, javax.validation, ant, >> aspectj, slf4j, etc >> 3) There are lots of resources coming from dependent jars and those are not >> shaded. For example: >> >> 283 Tue Dec 04 18:50:42 CET 2012 javacc.class >> 286 Tue Dec 04 18:50:42 CET 2012 jjdoc.class >> 235 Tue Dec 04 18:50:42 CET 2012 jjtree.class >> 0 Tue Dec 04 18:50:42 CET 2012 org/xwiki/shaded/javacc/ >> >> or >> >> 3783 Tue Dec 04 18:50:42 CET 2012 >> org/xwiki/shaded/javacc/utils/JavaFileGenerator.class >> 3693 Tue Dec 04 18:50:42 CET 2012 templates/CharStream.template >> 15990 Tue Dec 04 18:50:42 CET 2012 templates/JavaCharStream.template >> 867 Tue Dec 04 18:50:42 CET 2012 templates/MultiNode.template >> 1317 Tue Dec 04 18:50:42 CET 2012 templates/Node.template >> 5962 Tue Dec 04 18:50:42 CET 2012 templates/ParseException.template >> 12711 Tue Dec 04 18:50:42 CET 2012 templates/SimpleCharStream.template >> 3227 Tue Dec 04 18:50:42 CET 2012 templates/SimpleNode.template >> 4005 Tue Dec 04 18:50:42 CET 2012 templates/Token.template >> 368 Tue Dec 04 18:50:42 CET 2012 templates/TokenManager.template >> 4244 Tue Dec 04 18:50:42 CET 2012 templates/TokenMgrError.template >> 48 Tue Dec 04 18:50:42 CET 2012 version.properties >> >> So I'd like to keep a standalone distribution to make it easy to test XWiki >> Rendering but without any shading. >> >> Here's my +1 >> > > +0. > > I believe that it will be a good idea to shade a few critical libraries > that are likely to appear in incompatible version, and which are known > to cause problems otherwise and which work fine when shaded. I did a > quick check on dependency:tree and there doesn't seem to be any such > library, but we've had such problems with rhino and asm in the > xwiki-platform, and even log4j when the container prefers to use its own > version. The most problematic libraries AFAIK are the ones we exclude because they can't be shaded :) The problem is that right now we document this as if it was a working solution when it definitely isn't and I don't think it's good that we do so. Providing just a bundle to quickly get started if you don't have maven and making sure to mention the JAR hell issue and how to fix it if you want to include it in your project is the best solution I can think of. Actually what we could do to make sure there's no misunderstanding is just to provide a zip will all JARs and leave it to the user to use them in his project. Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
