so why brake the development environment? The trunk should not be a test bed but a development image. if something breaks the way people develop, it should be removed and tested as a patch.
David E Jones sent the following on 10/30/2008 1:38 PM: > > I don't know that we need to go that far. > > The easiest solution, for now, is to use the ofbiz ant script. Hopefully > we'll find better solutions in the near future. > > -David > > > On Oct 30, 2008, at 2:35 PM, BJ Freeman wrote: > >> then back it out till it is fixed. >> >> Adam Heath sent the following on 10/30/2008 1:30 PM: >>> I'll restate the problem. >>> >>> At startup, and goes and looks at the it's own global lib folder, and >>> adds any jars it finds to a brand new classloader. >>> >>> Then, those jars have to be able to find *all* their dependants, using >>> that same new classloader. >>> >>> So, the <scriptdef> classes have an internal dep on the BSFManager and >>> BSFExtension; those libraries have to be available to this new >>> classloader(or any of it's parents). >>> >>> The actual language implementations, forunately, do not; they can loaded >>> from a build.xml controlled path. >>> >>> If someone just types 'ant', which then uses the global classloader, >>> there is no way to add any additional libraries once the loader >>> heirarchy has been initialized. >>> >>> This is really a problem with the way ant is designed, unfortunately. >>> Classloaders are always notoriously hard to get right. >>> >>> >>> > > >