On Mon, 20 Jan 2003, James Strachan <[EMAIL PROTECTED]> wrote: > From: "Stefan Bodewig" <[EMAIL PROTECTED]> >> On Mon, 20 Jan 2003, James Strachan <[EMAIL PROTECTED]> >> > just passing on my observation that behaviour changed when I >> > switched Ant versions. >> >> But are you using build.sysclasspath=only as well in your >> experiments? > > I'm not sure I understand how this relates to running Ant with > forked JVMs running the JUnit test cases;
If you use nested <classpath> in <junit>, they'll get ignored - if build.sysclasspath=only. > this has always been a problematic area for me in the past. e.g. if > you want to use a different version of an XML parser than the one > Ant uses etc. Different issue, solution includeantruntime=false. >> > The Jelly AntTag used to check that a tag name was an Ant Task by >> > calling the following... >> > >> > project.getTaskDefinitions().containsKey( tagName ); Do you get a different result if you use contains instead of containsKey? I see that AntTaskTable only overrides contains (and will fix that shortly). > I can't remember all the details, but I remember Maven folks using a > tree of class loaders to prevent Maven, Ant or maven plugins from > polluting the system class loader. Yes. Having a clean classloader hierarchy is great. Unfortunately we can't do it in Ant as easily for backwards compatibility reasons. But we are improving that situation. > Using a single system class loader sounds like a problem as > Ant/JUnit would pollute it wouldn't they? This only happens with the specific build.sysclasspath setting - which is necessary for an environment like Gumo but probably completely unused otherwise. As Gump needs complete control over all classes that you load, it can only build the classpath upfront and force you to use it by allowing only the system classloader. Stefan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
