Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 59004 invoked from network); 14 Dec 2000 16:39:47 -0000 Received: from unknown (HELO mail.clientsoft.com) (38.136.106.13) by locus.apache.org with SMTP; 14 Dec 2000 16:39:47 -0000 Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 11:39:36 -0500 Message-ID: From: Bradley Williams To: "'ant-dev@jakarta.apache.org'" Subject: JUnit Task Error Date: Thu, 14 Dec 2000 11:39:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N This test runs fine out side of ant ! I get this error when running build with the junit task. Any ideas on what might be wrong ? [junit] Testcase: testRegAppServer took 0.18 sec [junit] Caused an ERROR [junit] loader constraints violated when linking org/xml/sax/InputSource class [junit] java.lang.LinkageError: loader constraints violated when linking org/xml/sax/InputSource class [junit] at com.clientsoft.webpack.util.CSUtils.read(CSUtils.java:248) [junit] at com.clientsoft.webpack.util.CSUtils.read(CSUtils.java:218) [junit] at com.clientsoft.webpack.util.CSUtils.read(CSUtils.java:231) [junit] at com.clientsoft.webpack.service.TNSServlet.init(TNSServlet.java:79) [junit] at com.clientsoft.util.harness.ServletHarness.(ServletHarness.java:100) [junit] at com.clientsoft.webpack.service.TNSServletTest.setUp(TNSServletTest.java:47) [junit] at junit.framework.TestCase.runBare(TestCase.java:127) [junit] at junit.framework.TestResult$1.protect(TestResult.java:100) [junit] at junit.framework.TestResult.runProtected(TestResult.java:117) [junit] at junit.framework.TestResult.run(TestResult.java:103) [junit] at junit.framework.TestCase.run(TestCase.java:120) [junit] at junit.framework.TestSuite.run(TestSuite.java:144) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRu nner.java:202) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTask.execute(JUnitTask.jav a:268) [junit] at org.apache.tools.ant.Target.execute(Target.java:142) [junit] at org.apache.tools.ant.Project.runTarget(Project.java:818) [junit] at org.apache.tools.ant.Project.executeTarget(Project.java:532) [junit] at org.apache.tools.ant.Project.executeTargets(Project.java:506) [junit] at org.apache.tools.ant.Main.runBuild(Main.java:420) [junit] at org.apache.tools.ant.Main.main(Main.java:149) [junit] BUILD FAILED -----Original Message----- From: James Cook [mailto:jimcook@iname.com] Sent: Thursday, December 14, 2000 10:50 AM To: ant-dev@jakarta.apache.org Subject: Ant 2.0 Consideration Since Ant 2.0 is being discussed, I thought I should offer an opinion. Most IDE's in use by developers display packages, source files, and support files such as jsp, html, properties, gif, jpg, etc. There are some exciting possibilities that can be achieved via Ant integration on these projects. However, because of the package/file metaphor used by these products, it clashes with Ant's task-based metaphor. Note that this clash doesn't preclude Ant integration, but it forces the developer into working with Ant instead of working with his/her files. Many power users won't care about this, but it can be a deterrent to more junior developers. Most IDE's will automatically compile all Java source files added to a project. Likewise, some will copy certain nodes (.properties, .gif) to an output directory automatically. Some IDE's allow the developer to invoke pre- or post-processing functions on a particular file. Ant already has more support (and definitely more flexibility) for supporting these additional tasks than any IDE on the market. In order for Ant to be integrated to the point that I am hoping, it will be necessary for several things to change in the Ant design. 1. A two-way Java class structure including Projects, Targets and Tasks. I think that there is a move towards this in Anteater. This approach IMHO is much better than exposing the DOM and using that as a read/write source. There is too much opportunity for ambiguity between DOM and the resulting Tasks. 2. Consistent support for how a Task handles File discovery needs to be enforced. The MatchingTask is a big step forward in this process, but not all Tasks use it. I may be wrong, but the Fileset concept seems to fly in the face of MatchingTask as well. It seems that File discovery can be achieved in two very different manners. 3. The reason I think File discovery is so important comes back to the fact that these IDEs utilitize a package/file structure. In order for Ant to be fully integrated, I need to be able to ask each Task if a particular file is affected by the Task. For example, given a particular File object, I should be able to ask a Copy Task if it will include this task. Since the Copy Task does not extend MatchingTask, this becomes impossible. Perhaps, a solution is to require Tasks to implement an isIncluded(File[])/isExcluded(File[]) method. 4. The converse of #3 would be the ability for a given Task object to include or exclude a specific file. This capability can be supported by the methods doInclude(File[]) or doExclude(File[]). I am interested in feedback on these issues. jim