OK, I have committed a patch which will fix this for Gump. It remains, however, a general problem. Most of our usage of the AntClassLoader is setting systemFirst to false. This is a danger zone for loader constraint violations. If we set these to true, however, we risk problems where a class, seemingly on the classpath, given to the classloader will not be found since the loading is being passed to the parent loader.
Whilst this is a backward compatability issue, we probably should change this. Certainly for most taskdefs and typedefs, it would probably be OK. We may want to investigate the ways in which the loader and build.sysclasspath interact and what is desirable. I'll try to do that in the next few days. There may be some scope to give the buildfile writer some control in some situations. Sam, I'd like to use the nightly Gump runs as a testing tool for these changes. Let me know if we need to co-ordinate. Conor ----- Original Message ----- From: "Conor MacNeill" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 09, 2001 2:35 PM Subject: RE: loader constraints violated when linking org/w3c/dom/Document class > > On Mon, 9 Jul 2001 13:31, Conor MacNeill wrote: > > > > There are three changes that *could* be relevent. > > > > > > I don't think these changes are the cause since if these had > > been an issue > > > a BuildException would have been thrown. Anyway, these changes were made > > > after Sam sent his email. > > > > Oh ;) > > Then the only other slightly relevent change I can see was > > implementation of > > AntClassLoader.getResources() but it is not imeadiately obvious to me how > > this would cause the error. Any ideas? > > > > No, other than loader contraint violations can depend on garbage collection > interaction, so not deterministic. I suspect it is not an Ant change that > triggered this but it may be an Ant bug. Like you I have been downloading > the relevant modules, but I ran out of time on the weekend - I'll have > another look tonight. > > Conor > >
