Yesterday's changes to junit and Gump
Posting to the general lists, as junit appears to have made it into the base infrastructure for many jakarta and xml projects... yesterday, changes to junit were made that broke a number of projects. It will be interesting to see how the junit folks respond... https://sourceforge.net/forum/forum.php?thread_id=150413forum_id=48542 - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yesterday's changes to junit and Gump
On Mon, 22 Oct 2001, Sam Ruby [EMAIL PROTECTED] wrote: yesterday, changes to junit were made that broke a number of projects. I guess their response will be that TestCase.name() has been deprecated since five months now and the alternative getName() is available in the 3.7 release. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Vote] BCEL @ Jakarta
Hi, I now have a proposal for BCEL which can be found here: http://www.apache.org/~jvanzyl/jakarta-bcel +1 -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ImportScrubberTask
On 10/21/01 11:52 PM, Jon Stevens [EMAIL PROTECTED] wrote: on 10/21/01 8:40 PM, Pier Fumagalli [EMAIL PROTECTED] wrote: Jon Stevens at [EMAIL PROTECTED] wrote: http://importscrubber.sourceforge.net/ant.html org.apache.tools.ant.taskdefs.optional.importscrubber.ImportScrubberTask Given that this isn't an official Jakarta project, shouldn't the tool choose another namespace? Indeed... Pier That said, I just tried running importscrubber against Scarab's code and it totally f*cked it up. I highly recommend not using it or at least being very careful with it. It works fine, but there is a problem with the imports being placed in the wrong place when there is text right after the package declaration. I asked Tom Copeland to fix this for me and he said he would get to it today. It does the job correctly, it just doesn't put the imports in the right place. -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] BCEL @ Jakarta
Jason van Zyl wrote: Hi, I now have a proposal for BCEL which can be found here: http://www.apache.org/~jvanzyl/jakarta-bcel +1 My non-binding +1 Conor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] BCEL @ Jakarta
On 10/22/01 9:55 AM, Pier Fumagalli [EMAIL PROTECTED] wrote: Jason van Zyl at [EMAIL PROTECTED] wrote: Hi, I now have a proposal for BCEL which can be found here: http://www.apache.org/~jvanzyl/jakarta-bcel +1 I like their project, the only thing I'm concerned about it is here: http://bcel.sourceforge.net/licensing.html Markus has agreed to change the licensing strictly over to the AL. We can't really keep dual licensing with LGPL, do the folks over there know about it? Because on their page they wrote (quote) I strongly encourage users to use the LGPL license and participate fully in the free software community. That's doesn't sound very ASF-like... :) :) But I'm not subbed on their lists, and I don't know the folks over there... Any comment? (Would love to hear from them directly, too! Feel free to forward) Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] BCEL @ Jakarta
Jason van Zyl at [EMAIL PROTECTED] wrote: I like their project, the only thing I'm concerned about it is here: http://bcel.sourceforge.net/licensing.html Markus has agreed to change the licensing strictly over to the AL. Big +1 then :) Pier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yesterday's changes to junit and Gump
We can quickly change it for Cactus. However this means that Cactus users will have to use JUnit 3.7 from now on ...But I guess it had to happen, someday and it's a normal event. I'll make the change. Thanks to GUMP for the good catch .. :) -Vincent - Original Message - From: Sam Ruby [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, October 22, 2001 2:44 PM Subject: Re: Yesterday's changes to junit and Gump Stefan Bodewig wrote: yesterday, changes to junit were made that broke a number of projects. I guess their response will be that TestCase.name() has been deprecated since five months now and the alternative getName() is available in the 3.7 release. That covers cactus, and perhaps soap and axis. What about the velocity, and xalan-smoketest failures? - Sam Ruby P.S. How the heck did that compile? Am I somehow using the version of junit which is checked into jakarta-ant? Is build.sysclasspath broken? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ImportScrubberTask
Hello Jon -
That's too bad that importscrubber messed up the Scarab source code.
Importscrubber is still definitely a work in progress, and there are some
things that it is definitely going to miss. For example, since the
compiler inlines references to static finals, and importscrubber looks in
the class file for class references it's going to miss those
references. Which is unfortunate. Also, if a string looks a lot like a
class name, Importscrubber may think its a class name and try to turn it
into an import statement.
At any rate, I'll take a look at how importscrubber mangles the Scarab
code and see if there's anything I can fix. Thanks for the feedback,
Yours,
Tom Copeland
[EMAIL PROTECTED]
703-317-5193
Jon Stevens
jon@latchkeyTo: [EMAIL PROTECTED]
[EMAIL PROTECTED]
.comcc: [EMAIL PROTECTED]
Subject: Re: ImportScrubberTask
10/21/2001
11:52 PM
on 10/21/01 8:40 PM, Pier Fumagalli [EMAIL PROTECTED] wrote:
Jon Stevens at [EMAIL PROTECTED] wrote:
http://importscrubber.sourceforge.net/ant.html
org.apache.tools.ant.taskdefs.optional.importscrubber.ImportScrubberTask
Given that this isn't an official Jakarta project, shouldn't the tool
choose
another namespace?
Indeed...
Pier
That said, I just tried running importscrubber against Scarab's code and it
totally f*cked it up. I highly recommend not using it or at least being
very
careful with it.
Tom, feel free to try yourself...I added the following to Scarab's
build.xml:
!-- ==
--
!-- Tool to create proper import statements
--
!-- ==
--
target name=scrub depends=om-peer,prepare
taskdef name=scrub
classname
=org.apache.tools.ant.taskdefs.optional.importscrubber.ImportScrub
berTask/
property name=tmp.dir value=tmp/
delete dir=${tmp.dir} quiet=true/
copy todir=${tmp.dir}/org
fileset dir=${build.src.scarab}/org/
/copy
javac srcdir=${tmp.dir}
destdir=${tmp.dir}
excludes=**/package.html,torque/**
debug=true
classpath refid=classpath/
classpath
fileset dir=${build.project.webinf.lib}
include name=**/torque*.jar/
/fileset
/classpath
/javac
scrub root=${tmp.dir} format=nobreaks recurse=true/
delete
fileset dir=${tmp.dir} includes=**/*.class/
/delete
copy todir=${src.java.dir.scarab}/org overwrite=true
fileset dir=${tmp.dir}/org/
/copy
/target
-jon
--
This email may contain confidential and proprietary information which is
for the sole use of the intended recipient. If you received this email in
error, please notify the sender and delete this email from your computer.
Any review, distribution or retransmission of or reliance on this email by
anyone other than the intended recipient is forbidden.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yesterday's changes to junit and Gump
On Mon, 22 Oct 2001, Sam Ruby [EMAIL PROTECTED] wrote: P.S. How the heck did that compile? Am I somehow using the version of junit which is checked into jakarta-ant? Is build.sysclasspath broken? Are you using build.sysclasspath in bootstrap-ant? If not, you've picked up the jar from Ant's CVS (which is JUnit 3.7) there. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yesterday's changes to junit and Gump
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 - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New jar dependency for Cactus
I'd like to ask if anyone sees a problem for using AspectJ (http://www.aspectj.org) with Cactus ? More specifically the license is MPL (http://aspectj.org/servlets/AJSite?channel=downloadsubChannel=license). Is that a problem ? I don't believe so, but just wanted to be sure. If it works, I think a lot of jakarta projects may find aspectj very useful. I highly recommend reading the tutorial : http://aspectj.org/doc/dist/tutorial.pdf Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ImportScrubberTask
on 10/22/01 6:22 AM, Jason van Zyl [EMAIL PROTECTED] wrote: It works fine, but there is a problem with the imports being placed in the wrong place when there is text right after the package declaration. I asked Tom Copeland to fix this for me and he said he would get to it today. It does the job correctly, it just doesn't put the imports in the right place. Run the ant target that I pasted here against Scarab and you will see that it does NOT work fine at all. I pasted it here so that I wouldn't get a response like you just gave me. Here is an example of some imports it f*cked up: [196][ src/org/tigris/scarab/om ]% more Attachment.java package org.tigris.scarab.om; import text.plain; import org.apache.fulcrum.upload.FileItem; import org.apache.torque.om.NumberKey; import org.apache.torque.om.Persistent; I never knew that text.plain is a proper import. :-) Here is another one: [197][ src/org/tigris/scarab/om ]% more IssueTemplateInfo.java package org.tigris.scarab.om; import email.RequireApproval.vm; import org.apache.turbine.Turbine; import org.apache.fulcrum.template.TemplateContext; import org.apache.torque.om.NumberKey; import org.apache.torque.om.UnsecurePersistent; import org.tigris.scarab.security.ScarabSecurity; import org.tigris.scarab.security.SecurityFactory; import org.tigris.scarab.tools.Email; import org.tigris.scarab.util.ScarabException; import org.tigris.scarab.services.module.ModuleEntity; Wow. When did Velocity files become ok to import? :-) It appears that in its search through files, it finds any mention of a foo.bar and sticks it into an import. That does not seem like a very good assumption. Another problem I noticed is that it imports java.util.Set when it doesn't need to as well. Yes, I compiled with debugging on. I'm starting to think that post processing JAD (the java decompiler) output would be a better idea. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] BCEL @ Jakarta
on 10/22/01 7:05 AM, Pier Fumagalli [EMAIL PROTECTED] wrote: Jason van Zyl at [EMAIL PROTECTED] wrote: I like their project, the only thing I'm concerned about it is here: http://bcel.sourceforge.net/licensing.html Markus has agreed to change the licensing strictly over to the AL. Big +1 then :) Pier FYI, it is 'ASF License' or 'ASFL'...not 'AL'. The license belongs to the 'Apache Software Foundation', not 'Apache'. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: New jar dependency for Cactus
on 10/22/01 9:27 AM, Vincent Massol [EMAIL PROTECTED] wrote: I'd like to ask if anyone sees a problem for using AspectJ (http://www.aspectj.org) with Cactus ? More specifically the license is MPL (http://aspectj.org/servlets/AJSite?channel=downloadsubChannel=license). Is that a problem ? I don't believe so, but just wanted to be sure. If it works, I think a lot of jakarta projects may find aspectj very useful. I highly recommend reading the tutorial : http://aspectj.org/doc/dist/tutorial.pdf Thanks -Vincent From everything that I have ever heard from ASF board members, the MPL 1.1 and higher (not 1.0) is an ok license to combine ASF software with. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ImportScrubberTask
Jon Stevens at [EMAIL PROTECTED] wrote: import email.RequireApproval.vm; Wow. When did Velocity files become ok to import? :-) You didn't know? They're adding those to the VM spec, so that you can directly write in Velocity without having the hassle to pass thru Java :) :) Pier (being ready to be flamed by JG! :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ImportScrubberTask
On 10/22/01 1:04 PM, Jon Stevens [EMAIL PROTECTED] wrote: on 10/22/01 6:22 AM, Jason van Zyl [EMAIL PROTECTED] wrote: It works fine, but there is a problem with the imports being placed in the wrong place when there is text right after the package declaration. I asked Tom Copeland to fix this for me and he said he would get to it today. It does the job correctly, it just doesn't put the imports in the right place. Run the ant target that I pasted here against Scarab and you will see that it does NOT work fine at all. I pasted it here so that I wouldn't get a response like you just gave me. I only ran it on a small body of source, but Scarab is a good test bed. Here is an example of some imports it f*cked up: [196][ src/org/tigris/scarab/om ]% more Attachment.java package org.tigris.scarab.om; import text.plain; import org.apache.fulcrum.upload.FileItem; import org.apache.torque.om.NumberKey; import org.apache.torque.om.Persistent; I never knew that text.plain is a proper import. :-) Here is another one: [197][ src/org/tigris/scarab/om ]% more IssueTemplateInfo.java package org.tigris.scarab.om; import email.RequireApproval.vm; import org.apache.turbine.Turbine; import org.apache.fulcrum.template.TemplateContext; import org.apache.torque.om.NumberKey; import org.apache.torque.om.UnsecurePersistent; import org.tigris.scarab.security.ScarabSecurity; import org.tigris.scarab.security.SecurityFactory; import org.tigris.scarab.tools.Email; import org.tigris.scarab.util.ScarabException; import org.tigris.scarab.services.module.ModuleEntity; Wow. When did Velocity files become ok to import? :-) But it did a pretty good job, I think after a couple rounds of fixes it will be fine. It appears that in its search through files, it finds any mention of a foo.bar and sticks it into an import. That does not seem like a very good assumption. Poking around in the constants pool isn't necessarily straight forward even though BCEL makes it much easier. Another problem I noticed is that it imports java.util.Set when it doesn't need to as well. I think that's a superclass problem. Same thing I ran into with the little hack I whipped up. Yes, I compiled with debugging on. I'm starting to think that post processing JAD (the java decompiler) output would be a better idea. I think in a couple of days it will do the trick just fine. I ran it on the Tambora source and it wasn't that bad. It doesn't work yet but it's pretty close. -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ImportScrubberTask
on 10/22/01 10:56 AM, Jason van Zyl [EMAIL PROTECTED] wrote: I only ran it on a small body of source, but Scarab is a good test bed. Scarab is something like 256 classes...most of it is Torque generated though... -jon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ImportScrubberTask
Jon Stevens wrote: on 10/22/01 10:23 AM, Pier Fumagalli [EMAIL PROTECTED] wrote: You didn't know? They're adding those to the VM spec, so that you can directly write in Velocity without having the hassle to pass thru Java :) :) Pier (being ready to be flamed by JG! :) Na...we would have to rename Velocity - JSP. :-) I wonder how many people have tried importing a compiled JSP page. Oh wait, you can't easily do that because Jasper makes up some f*cked up name for the class because no one could figure out how to implement reloading properly. :-) -jon You might want to qualilfy the above statemenet. Jasper in Tomcat 4 uses a sane scheme for package and class naming that supports reloading of JSP pages. And it performs 25-33% faster due to just that change. (Taking this even further off topic) ;-) -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] BCEL @ Jakarta
+1 -- Cheers, Pete *---* PROGRAM: n. a magic spell cast over a computer allowing it to turn one's input into error messages. v.t. to engage in a pastime similar to banging one's head against a wall, but with fewer opportunities for reward. *---* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ImportScrubberTask
Hi Dan - Thanks very much. Yup, a lot of the constant strings that BCEL emits look just like the JNI method signature components. In a previous life I wrote a LOT of Win32 JNI and got very familiar with all that gibberish. Now I'm a happy pure-Java programmer :-) Thanks, Tom Copeland [EMAIL PROTECTED] 703-317-5193 Daniel Rall dlr@finemaltcodingTo: [EMAIL PROTECTED] .com cc: Sent by: Subject: Re: ImportScrubberTask [EMAIL PROTECTED] coding.com 10/22/2001 04:21 PM Please respond to general [EMAIL PROTECTED] writes: That's too bad that importscrubber messed up the Scarab source code. Importscrubber is still definitely a work in progress, and there are some things that it is definitely going to miss. For example, since the compiler inlines references to static finals, and importscrubber looks in the class file for class references it's going to miss those references. Which is unfortunate. Also, if a string looks a lot like a class name, Importscrubber may think its a class name and try to turn it into an import statement. When writing JNI code which references Java classes, one has to use special markup on the fully qualified class names. I.e. Lorg/apache/turbine/Turbine; would be the string literal corresponding to the class org.apache.turbine.Turbine, and something like (Ljava/lang/String;Ljava/lang/String;)V to denote a method which takes two String parameters. Looking at some bytecode using `strings`, I notice that this seems to apply to at least part of a method signature. Not a lot of help here, but maybe something to think about. shrug/ Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This email may contain confidential and proprietary information which is for the sole use of the intended recipient. If you received this email in error, please notify the sender and delete this email from your computer. Any review, distribution or retransmission of or reliance on this email by anyone other than the intended recipient is forbidden. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yesterday's changes to junit and Gump
Shane Curcuru wrote: 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. The way gump works is that it disables classpth elements and then runs everything off of the system classpath. My preference is that people with the abilty to change what gump runs actually demonstrate an ability to run gump themselves. Towards that end, I've been focusing on documentation, performance, and ease-of-use lately. See http://jakarta.apache.org/gump/usage.html . In the specific case of xml-xalan2-smoketest on Windows, these are the actual commands that gump uses: SET CLASSPATH=%JAVA_HOME%\lib\tools.jar SET CLASSPATH=%CLASSPATH%;D:\path\xml-xalan\test\java\build SET CLASSPATH=%CLASSPATH%;D:\path\jakarta-ant\dist\lib\ant.jar SET CLASSPATH=%CLASSPATH%;D:\path\jakarta-ant\dist\lib\optional.jar SET CLASSPATH=%CLASSPATH%;D:\path\xml-xerces\java\build\xerces.jar SET CLASSPATH=D:\path\xml-xalan\java\build\xalan-j_version\bin\xalan.jar;%CLASSPATH% java org.apache.tools.ant.Main -Dbuild.sysclasspath=only smoketest.gump Obviously, adjust the paths accordingly. - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] BCEL @ Jakarta
+1 - Sam Ruby - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yesterday's changes to junit and Gump
Sam Ruby [EMAIL PROTECTED] writes: Stefan Bodewig wrote: I guess their response will be that TestCase.name() has been deprecated since five months now and the alternative getName() is available in the 3.7 release. That covers cactus, and perhaps soap and axis. What about the velocity, and xalan-smoketest failures? If the Velocity failure turns out to be JUnit related, I'll make whatever changes are necessary. Sam, I'd appreciate a poke if it comes to that. Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Vote] BCEL @ Jakarta
Jason van Zyl [EMAIL PROTECTED] writes: Hi, I now have a proposal for BCEL which can be found here: http://www.apache.org/~jvanzyl/jakarta-bcel +1 Here's my non-PMC +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yesterday's changes to junit and Gump
Sam Ruby [EMAIL PROTECTED] writes: Daniel Rall wrote: If the Velocity failure turns out to be JUnit related, I'll make whatever changes are necessary. Sam, I'd appreciate a poke if it comes to that. You can count on a _DAILY_ poke until this is resolved. ;-) O, *those* messages. Anyone know how to restore data sent to /dev/null? J/K Sam. ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Yesterday's changes to junit and Gump
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ImportScrubberTask
[EMAIL PROTECTED] writes: That's too bad that importscrubber messed up the Scarab source code. Importscrubber is still definitely a work in progress, and there are some things that it is definitely going to miss. For example, since the compiler inlines references to static finals, and importscrubber looks in the class file for class references it's going to miss those references. Which is unfortunate. Also, if a string looks a lot like a class name, Importscrubber may think its a class name and try to turn it into an import statement. When writing JNI code which references Java classes, one has to use special markup on the fully qualified class names. I.e. Lorg/apache/turbine/Turbine; would be the string literal corresponding to the class org.apache.turbine.Turbine, and something like (Ljava/lang/String;Ljava/lang/String;)V to denote a method which takes two String parameters. Looking at some bytecode using `strings`, I notice that this seems to apply to at least part of a method signature. Not a lot of help here, but maybe something to think about. shrug/ Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
