Rowf? (Picture a dog cocking their head sideways with one ear up in the air)
I can't comment on velocity or junit build failures, but I'm pretty certain that Xalan smoketest problems shouldn't be affecting them. As for the last two xml-xalan2-smoketest problems, the problems of Sunday appear cleared up, and Monday's build's smoketest is all passing except for one new issue: http://jakarta.apache.org/builds/gump/2001-10-22/xml-xalan2-smoketest.html .. .. shows that *only* the newly added portion of extensions tests are failing apparently-because of: javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: java.lang.ClassNotFoundException: javaSample3 .. which to me means a classpath(s) handling difference between my environment and gump's environment. So I'm 95%+ sure that Monday's Xalan build is functioning normally, and that Monday's smoketest is failing only because I don't understand yet how to make my test changes work correctly with gump. (But I'm hoping it's an easy enlightenment process...) So: what's the simplest way for a project that's run within gump to change it's build process to explicitly add newly compiled classes or jars to the effective classpath for just part of it's targets? I.e. the xml-xalan/test target has several different compiled outputs, depending on what targets you run. Then when running various testing targets, I explicitly want to add a couple of external dependencies (xalan.jar, your-parser.jar, bsf.jar, etc.) to the classpath along with some of the compiled outputs that I just produced. xml-xalan/test 'compile' puts the guts of the testing framework and many of the api tests into testxsl.jar. But I also compile separately a number of bugzilla tests and extensions tests just into local /build/*.classes files, since they're packageless and often change. So now the new smoketest.extensions part of the smoketest needs to have both all the rest of the classpath stuff (xalan.jar, etc.; testxsl.jar) as well as this special directory of compiled classes. What's the easiest way to get things like these running in gump and to update them in the future? I thought I was already close to what gump needed since the specific targets that run these tests already manage <classpath> elements inside my build.xml file, but obviously I'm missing something else. I'm hoping that we can find a general solution, both that's reasonably simple to implement in my specific project's build.xml file and that doesn't require Sam and others with gump commit privs to have to keep making changes. - Shane ---- Sam Ruby wrote ---- > Stefan Bodewig wrote: > > > >> What about the velocity, and xalan-smoketest failures? > > > >The velocity change is probably not related to JUnit at all, it > >probably is the latest change to Ant's Project.java (Texen is getting > >a warning because it is redefining a task and gets some unexpected >output). > > There is something more going on. Yesterday, the 6 pm pacific time version of Ant, velocity worked with the previous day's junit but not with the junit that was current. However, I can not make the same statement about the 6 am pacific time versions of these components. > It's rare that multiple events such as these (Geir also committed a patch that might be contributing to this) conspire this way! > >Without digging too deep into it, I'd blame the xalan-smoketest > >failure to the changes to xml-xalan/test/build.xml or > >xml-xalan/test/test.properties, not JUnit either. > I haven't tried the various permutations, but you appear to be right - simply backing out the junit changes is not sufficient to > get this test passing again. > Stefan, Geir, Shane, others, let me know if it would be helpful for me to try various combinations of backing out changes in order to isolate when the failure was introduced. > With gump, it is as easy as: > cd junit > cvs update -D 2001/10/20 > build junit > build jakarta-velocity-test Yeah, someday I'll figure out how to get a gump running in our lab so we can reproduce the gump-level issues for some of the main xalan committers. A cold and our next release are getting in the way right now. -sc - Shane
