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.
>>>
>>>
>>>
> 
> 
> 

Reply via email to