DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=38799>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=38799 Summary: <junit> task should work so long as junit.jar present in <classpath> even if not among Ant libs Product: Ant Version: 1.3 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Optional Tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED],dev@ant.apache.org OtherBugsDependingO 6606 nThis: A general problem with <junit> has come up repeatedly, as described well here: http://issues.apache.org/bugzilla/show_bug.cgi?id=6606#c22 I am splitting this off into a separate issue as #6606 seems to have a lot of other meanings and I want to be concrete. The problem is that if you have ant-junit.jar in your Ant lib dir (the default situation if you have installed Ant) but you do not have junit.jar in your Ant lib dir or $CLASSPATH or -lib etc. (again, the default situation), the <junit> task does not work. This is true even if you have explicitly added junit.jar to the <classpath> for the task (<junit>, not <taskdef> which cannot work on a task already in your lib dir). That doesn't make much sense and it imposes an artificial requirement on people to adjust their Ant startup classpath. That means that you cannot write a completely self-contained Ant project that runs unit tests. This patch fixes that. While I cannot find Tobias' original proposed patch, I think this accomplishes as much, and furthermore works in unforked mode. I'm not really sure how to unit-test this since the Ant unit tests assume a lot of environment is set up, and specifically they will assume that junit.jar is on the test classpath. So I'm relying on manual testing of various situations: 1. Forked mode vs. unforked mode. 2. junit.jar on system CP vs. not. 3. junit.jar in test <classpath> vs. not. Desired behavior is that tests run fine if either #2 or #3 or both. (If neither, a simple error is reported.) Current behavior is that tests do not run if #3 but not #2. Compatibility: unless I made a mistake, should be fully compatible. Any build scripts which worked before should continue to work the same way: junit.jar must have been on system CP, and <junit> will behave as it did previously. The change should only affect situations where junit.jar was not on system CP, which could not have worked before. The patch is a bit icky since it needs to use some reflection to isolate the junit.jar-dependent portions of the task. The result is mostly transparent and should not harm existing code subclassing some of the classes in this package, I think, but it does add some to the complexity of this task. Perhaps someone knowledgeable could simplify it but I was afraid of breaking foreign code referring to these classes, which are all public. Note that since both "halves" of the task remain in the same source root, the compiler does not enforce the separation - a full fix would move the junit.jar-dependent classes to a separate source root, to ensure that they are not statically accessible from the main source root, and ideally even to put them in a separate JAR file at runtime. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
