Hi, Xalan has been added to create Junit HTML report. Maybe we can simply "exclude" xalan* from the fileset for the moment. I will try to see if the latest xalan work with Junit and let you know. Vincent
> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] On Behalf > Of Andrew Stevens > Sent: dimanche 3 mars 2002 1:04 > To: [EMAIL PROTECTED] > Subject: Re: [Xdoclet-devel] Samples won't build? > > > Eureka! And I find it hard to believe I'm the only one this > is affecting. > > If I explicitly add crimson.jar first in the project.class.path with > <fileset dir="lib"> > <include name="crimson.jar"/> > <include name="**/*.jar" /> > </fileset> > then everything validates perfectly. My guess is that > xalan-2.0.0.jar is > getting put before it in the classpath, and is what's causing > the problem. > > The exception mentions > org.apache.xerces.jaxp.SAXParserFactoryImpl - the > xalan jar has a file > META-INF/services/javax.xml.parsers.SAXParserFactory > containing the string > "org.apache.xerces.jaxp.SAXParserFactoryImpl", which > means JAXP will want to use it as the SAX parser (and, of > course, it isn't > found). With crimson first on the path, it gets set up to > that instead. > > What determines the order of the fileset's jars in <include > name="**/*.jar" /> anyway? (so we can make sure crimson comes first) > > Incidentally, 2.0.0 seems quite an old version of xalan (I > assume that's > what's in the jar based on its name) - the current one on > xml.apache.org > is 2.3.1. > > > Andrew. > > > A wise old hermit known only as Andrew Stevens > <[EMAIL PROTECTED]> once said: > > > The exception's being thrown during XML validation; it's > not just the > > deploymentdescriptor subtask that's affected - if I set > validatexml to > > false on that one it just fails on the weblogic subtask > instead. If I > > set it to false on weblogic, it fails at the jrun task instead... > > > > The ejb-jar.xml file *is* valid, though - it's validated okay by > > Netbeans' XML module (at least, once I change the DTD's > system ID to > > point to the local disk copy). So, it appears to be a problem with > > XDoclet's validator. > > > > I don't suppose the java.io.File->java.net.URL changes could have > > messed up the validation? (e.g. by stopping it resolving > the DTD) The > > only change to xdoclet.util.XmlValidator since my i18n stuff (and I > > know it worked okay after that) is "Refactored the use of > java.io.File > > for reading to use java.net.URL instead. This is cleaner > and safer, and > > makes it possible to read templates from within other jar > files" What > > about the subsequent change to fix the file:/// problem for > > templatefile? Would that need anything equivalent doing in the > > XmlValidator too? > > > > Again, am I the only one that's getting this? > > > > > > Andrew. > > > > > > A wise old hermit known only as Andrew Stevens > > <[EMAIL PROTECTED]> once said: > > > > > Is it just me, or is something wrong with building the > samples? I > > > do > > > a total-clean, build the main dist, go the the samples > and build, and > > > I get > > > > > > [ejbdoclet] javax.xml.parsers.FactoryConfigurationError: > > > java.lang.ClassNotFoundException: > > > org.apache.xerces.jaxp.SAXParserFactoryImpl > > > [ejbdoclet] at > > > > > > > > > javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:1 > > 50 > > > ) > > > [ejbdoclet] at > > > xdoclet.util.XmlValidator.validate(XmlValidator.java:169) > > > [ejbdoclet] at > xdoclet.XmlSubTask.engineFinished(XmlSubTask.java:132) > > > [ejbdoclet] at > > > xdoclet.TemplateSubTask.startEngine(TemplateSubTask.java:550) > > > [ejbdoclet] at > > > xdoclet.TemplateSubTask.startProcess(TemplateSubTask.java:354) > > > > > > > > > Andrew. > > _______________________________________________ > Xdoclet-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-devel > > _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
