On 12/04/2012 03:34 PM, Vincent Massol wrote: > > 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. >
+1, that's even better IMO than hiding dependencies in a big jar, which will cause problems. -- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
