Re: svn commit: r708924 - in /ofbiz/trunk/framework/base/lib: ant-apache-bsf-1.7.0.jar ant-nodeps-1.7.0.jar bsf-2.4.0.jar scripting/bsf-2.4.0.jar

[David E Jones]

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

[Adam Heath-2]

BJ Freeman wrote:
> then back it out till it is fixed.

Er, you can't fix it, it's an ant problem.

If you have a half-modified global ant(one that has part of the optional
libs, but not all), then the global ant is broken.  That's not something
that ofbiz can deal with.

A completely plain, clean ant install works with a fresh ofbiz checkout.
 It's only those global ants that have been partly extended that don't work.

[BJ Freeman]

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

[BJ Freeman]

I have a checkout that is only svn.
I don't add or change anything.
and it is broke, per the data already shown, on a windows xp.


Adam Heath sent the following on 10/30/2008 1:44 PM:

> BJ Freeman wrote:
>> then back it out till it is fixed.
>
> Er, you can't fix it, it's an ant problem.
>
> If you have a half-modified global ant(one that has part of the optional
> libs, but not all), then the global ant is broken.  That's not something
> that ofbiz can deal with.
>
> A completely plain, clean ant install works with a fresh ofbiz checkout.
>  It's only those global ants that have been partly extended that don't work.
>
>

[BJ Freeman]

i should clarify that ant build works
but build thru eclipse does not


BJ Freeman sent the following on 10/30/2008 1:50 PM:

> I have a checkout that is only svn.
> I don't add or change anything.
> and it is broke, per the data already shown, on a windows xp.
>
>
> Adam Heath sent the following on 10/30/2008 1:44 PM:
>> BJ Freeman wrote:
>>> then back it out till it is fixed.
>> Er, you can't fix it, it's an ant problem.
>>
>> If you have a half-modified global ant(one that has part of the optional
>> libs, but not all), then the global ant is broken.  That's not something
>> that ofbiz can deal with.
>>
>> A completely plain, clean ant install works with a fresh ofbiz checkout.
>>  It's only those global ants that have been partly extended that don't work.
>>
>>
>
>

[Adam Heath-2]

BJ Freeman wrote:
> I have a checkout that is only svn.
> I don't add or change anything.
> and it is broke, per the data already shown, on a windows xp.

Local ant or global ant?

[Adam Heath-2]

BJ Freeman wrote:
> i should clarify that ant build works
> but build thru eclipse does not

Then how does eclipse call ant?  If the classloader it uses to call ant
only has a small part of ant's optional libs, then there is nothing more
we can do.  The classpath eclipse uses to call ant needs to be fixed.

[Adam Heath-2]

BJ Freeman wrote:
> 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.

It's not ofbiz that is broken, it the ant install that is.

Classloader heiarchay(guess, but probably pretty accurate)

SystemLoader -> AntBaseLoader -> build.xml loaders(multiple)

Any class loaded by a particular loader can only have bytecode level
depends on classes loaded by it's same loader, or a parent.  This is
just the way classloaders work.

What is occuring in these cases, is that the ScriptDefTask.java,
provided by ant, is loaded by the AntBaseLoader, but then the
BSFManager/BSFException class that it needs is not available in either
the AntBaseLoader, nor the SystemLoader.

The fix is to make certain the ScriptDefTask is not in the global ant
library, or move the bsf.jar into the global ant library.

If you are having this problem, then its the ant install that is broken.
 There's nothing ofbiz can do to fix the global ant.

[Adam Heath-2]

Adam Heath wrote:

> BJ Freeman wrote:
>> 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.
>
> It's not ofbiz that is broken, it the ant install that is.
>
> Classloader heiarchay(guess, but probably pretty accurate)
>
> SystemLoader -> AntBaseLoader -> build.xml loaders(multiple)
>
> Any class loaded by a particular loader can only have bytecode level
> depends on classes loaded by it's same loader, or a parent.  This is
> just the way classloaders work.
>
> What is occuring in these cases, is that the ScriptDefTask.java,
> provided by ant, is loaded by the AntBaseLoader, but then the
> BSFManager/BSFException class that it needs is not available in either
> the AntBaseLoader, nor the SystemLoader.
>
> The fix is to make certain the ScriptDefTask is not in the global ant
> library, or move the bsf.jar into the global ant library.
>
> If you are having this problem, then its the ant install that is broken.
>  There's nothing ofbiz can do to fix the global ant.

Or look at http://ant.apache.org/manual/install.html#optionalTasks

[BJ Freeman]

this would be done in the .classpath included in the trunk
if eclipse is not longer supported in the trunk then the .project and
.classpath should be removed.
also I think that a vote should be done on removing Eclipse.
However that will effect many who develop with eclipse.
so it should be removed till a fix is found.


Adam Heath sent the following on 10/30/2008 2:01 PM:
> BJ Freeman wrote:
>> i should clarify that ant build works
>> but build thru eclipse does not
>
> Then how does eclipse call ant?  If the classloader it uses to call ant
> only has a small part of ant's optional libs, then there is nothing more
> we can do.  The classpath eclipse uses to call ant needs to be fixed.
>
>

[Jacques Le Roux]

I guess it uses its plugin. For me it's eclipse3.4\plugins\org.apache.ant_1.7.0.v200803061910\bin

A bit late here, but I'd have a look

Jacques

From: "Adam Heath" <[hidden email]>
> BJ Freeman wrote:
>> i should clarify that ant build works
>> but build thru eclipse does not
>
> Then how does eclipse call ant?  If the classloader it uses to call ant
> only has a small part of ant's optional libs, then there is nothing more
> we can do.  The classpath eclipse uses to call ant needs to be fixed.
>

[Adam Heath-2]

BJ Freeman wrote:
> this would be done in the .classpath included in the trunk
> if eclipse is not longer supported in the trunk then the .project and
> .classpath should be removed.
> also I think that a vote should be done on removing Eclipse.
> However that will effect many who develop with eclipse.
> so it should be removed till a fix is found.

<rant>
Oh my, that is so broken.  That is a stupid way to make eclipse work.
Combining libraries that the *code* needs to compile, with libraries
that the *build* system needs.  Shame on eclipse for doing it that way.
 Bad monkey, no cookie for you.
</rant>

I've added the new ant jars in 709250.  Don't use eclipse, so can't test.

[Scott Gray]

You should be able to change your ant home directory from the build
configuration under the classpath tab.  Change it to use
framework/base and everything should be fine.

Regards
Scott

2008/10/31 BJ Freeman <[hidden email]>:

> this would be done in the .classpath included in the trunk
> if eclipse is not longer supported in the trunk then the .project and
> .classpath should be removed.
> also I think that a vote should be done on removing Eclipse.
> However that will effect many who develop with eclipse.
> so it should be removed till a fix is found.
>
>
> Adam Heath sent the following on 10/30/2008 2:01 PM:
>> BJ Freeman wrote:
>>> i should clarify that ant build works
>>> but build thru eclipse does not
>>
>> Then how does eclipse call ant?  If the classloader it uses to call ant
>> only has a small part of ant's optional libs, then there is nothing more
>> we can do.  The classpath eclipse uses to call ant needs to be fixed.
>>
>>
>

[BJ Freeman]

hehehehe

Adam Heath sent the following on 10/30/2008 2:29 PM:

> BJ Freeman wrote:
>> this would be done in the .classpath included in the trunk
>> if eclipse is not longer supported in the trunk then the .project and
>> .classpath should be removed.
>> also I think that a vote should be done on removing Eclipse.
>> However that will effect many who develop with eclipse.
>> so it should be removed till a fix is found.
>
> <rant>
> Oh my, that is so broken.  That is a stupid way to make eclipse work.
> Combining libraries that the *code* needs to compile, with libraries
> that the *build* system needs.  Shame on eclipse for doing it that way.
>  Bad monkey, no cookie for you.
> </rant>
>
> I've added the new ant jars in 709250.  Don't use eclipse, so can't test.
>
>

[Jacques Le Roux]

Sorry but the problem remains

Jacques

From: "Adam Heath" <[hidden email]>

> BJ Freeman wrote:
>> this would be done in the .classpath included in the trunk
>> if eclipse is not longer supported in the trunk then the .project and
>> .classpath should be removed.
>> also I think that a vote should be done on removing Eclipse.
>> However that will effect many who develop with eclipse.
>> so it should be removed till a fix is found.
>
> <rant>
> Oh my, that is so broken.  That is a stupid way to make eclipse work.
> Combining libraries that the *code* needs to compile, with libraries
> that the *build* system needs.  Shame on eclipse for doing it that way.
> Bad monkey, no cookie for you.
> </rant>
>
> I've added the new ant jars in 709250.  Don't use eclipse, so can't test.
>

[Jacques Le Roux]

OF course, it works  but IMO it's not a very satisfying solution even if we can generalize for all configurations at the workspace
level using the Runtime Ant Preferences.
Because it's a new setup one have to do for every new Eclipse environments (I already imagine the number of questions we will have
from that...)

Jacques

From: "Scott Gray" <[hidden email]>

> You should be able to change your ant home directory from the build
> configuration under the classpath tab.  Change it to use
> framework/base and everything should be fine.
>
> Regards
> Scott
>
> 2008/10/31 BJ Freeman <[hidden email]>:
>> this would be done in the .classpath included in the trunk
>> if eclipse is not longer supported in the trunk then the .project and
>> .classpath should be removed.
>> also I think that a vote should be done on removing Eclipse.
>> However that will effect many who develop with eclipse.
>> so it should be removed till a fix is found.
>>
>>
>> Adam Heath sent the following on 10/30/2008 2:01 PM:
>>> BJ Freeman wrote:
>>>> i should clarify that ant build works
>>>> but build thru eclipse does not
>>>
>>> Then how does eclipse call ant?  If the classloader it uses to call ant
>>> only has a small part of ant's optional libs, then there is nothing more
>>> we can do.  The classpath eclipse uses to call ant needs to be fixed.
>>>
>>>
>>
>

[Jacques Le Roux]

To be clear  (and maybe for future FAQ)

In Eclipse : Windows Menu, then Preferences option, Ant/Runtime, from Ant Home button choice "framework/base"

Jacques

From: "Jacques Le Roux" <[hidden email]>

> OF course, it works  but IMO it's not a very satisfying solution even if we can generalize for all configurations at the workspace
> level using the Runtime Ant Preferences.
> Because it's a new setup one have to do for every new Eclipse environments (I already imagine the number of questions we will have
> from that...)
>
> Jacques
>
> From: "Scott Gray" <[hidden email]>
>> You should be able to change your ant home directory from the build
>> configuration under the classpath tab.  Change it to use
>> framework/base and everything should be fine.
>>
>> Regards
>> Scott
>>
>> 2008/10/31 BJ Freeman <[hidden email]>:
>>> this would be done in the .classpath included in the trunk
>>> if eclipse is not longer supported in the trunk then the .project and
>>> .classpath should be removed.
>>> also I think that a vote should be done on removing Eclipse.
>>> However that will effect many who develop with eclipse.
>>> so it should be removed till a fix is found.
>>>
>>>
>>> Adam Heath sent the following on 10/30/2008 2:01 PM:
>>>> BJ Freeman wrote:
>>>>> i should clarify that ant build works
>>>>> but build thru eclipse does not
>>>>
>>>> Then how does eclipse call ant?  If the classloader it uses to call ant
>>>> only has a small part of ant's optional libs, then there is nothing more
>>>> we can do.  The classpath eclipse uses to call ant needs to be fixed.
>>>>
>>>>
>>>
>>
>

[BJ Freeman]

updated SVN
run as for the build.xml

ofbiz_svn\build.xml:126: The following error occurred while executing
this line:

ofbiz_svn\framework\build.xml:22: The following error occurred while
executing this line:

ofbiz_svn\macros.xml:63: Could not create type ofbizscriptdef due to
java.lang.NoClassDefFoundError: org/apache/bsf/BSFException



Adam Heath sent the following on 10/30/2008 2:29 PM:

> BJ Freeman wrote:
>> this would be done in the .classpath included in the trunk
>> if eclipse is not longer supported in the trunk then the .project and
>> .classpath should be removed.
>> also I think that a vote should be done on removing Eclipse.
>> However that will effect many who develop with eclipse.
>> so it should be removed till a fix is found.
>
> <rant>
> Oh my, that is so broken.  That is a stupid way to make eclipse work.
> Combining libraries that the *code* needs to compile, with libraries
> that the *build* system needs.  Shame on eclipse for doing it that way.
>  Bad monkey, no cookie for you.
> </rant>
>
> I've added the new ant jars in 709250.  Don't use eclipse, so can't test.
>
>

[Jacques Le Roux]

BTW we can revert r709250 : it's useless

Jacques

From: "Jacques Le Roux" <[hidden email]>

> To be clear  (and maybe for future FAQ)
>
> In Eclipse : Windows Menu, then Preferences option, Ant/Runtime, from Ant Home button choice "framework/base"
>
> Jacques
>
> From: "Jacques Le Roux" <[hidden email]>
>> OF course, it works  but IMO it's not a very satisfying solution even if we can generalize for all configurations at the
>> workspace level using the Runtime Ant Preferences.
>> Because it's a new setup one have to do for every new Eclipse environments (I already imagine the number of questions we will
>> have from that...)
>>
>> Jacques
>>
>> From: "Scott Gray" <[hidden email]>
>>> You should be able to change your ant home directory from the build
>>> configuration under the classpath tab.  Change it to use
>>> framework/base and everything should be fine.
>>>
>>> Regards
>>> Scott
>>>
>>> 2008/10/31 BJ Freeman <[hidden email]>:
>>>> this would be done in the .classpath included in the trunk
>>>> if eclipse is not longer supported in the trunk then the .project and
>>>> .classpath should be removed.
>>>> also I think that a vote should be done on removing Eclipse.
>>>> However that will effect many who develop with eclipse.
>>>> so it should be removed till a fix is found.
>>>>
>>>>
>>>> Adam Heath sent the following on 10/30/2008 2:01 PM:
>>>>> BJ Freeman wrote:
>>>>>> i should clarify that ant build works
>>>>>> but build thru eclipse does not
>>>>>
>>>>> Then how does eclipse call ant?  If the classloader it uses to call ant
>>>>> only has a small part of ant's optional libs, then there is nothing more
>>>>> we can do.  The classpath eclipse uses to call ant needs to be fixed.
>>>>>
>>>>>
>>>>
>>>
>>
>

[Adrian Crum]

Let's wait on that.

-Adrian

Jacques Le Roux wrote:

> BTW we can revert r709250 : it's useless
>
> Jacques
>
> From: "Jacques Le Roux" <[hidden email]>
>> To be clear  (and maybe for future FAQ)
>>
>> In Eclipse : Windows Menu, then Preferences option, Ant/Runtime, from
>> Ant Home button choice "framework/base"
>>
>> Jacques
>>
>> From: "Jacques Le Roux" <[hidden email]>
>>> OF course, it works  but IMO it's not a very satisfying solution even
>>> if we can generalize for all configurations at the workspace level
>>> using the Runtime Ant Preferences.
>>> Because it's a new setup one have to do for every new Eclipse
>>> environments (I already imagine the number of questions we will have
>>> from that...)
>>>
>>> Jacques
>>>
>>> From: "Scott Gray" <[hidden email]>
>>>> You should be able to change your ant home directory from the build
>>>> configuration under the classpath tab.  Change it to use
>>>> framework/base and everything should be fine.
>>>>
>>>> Regards
>>>> Scott
>>>>
>>>> 2008/10/31 BJ Freeman <[hidden email]>:
>>>>> this would be done in the .classpath included in the trunk
>>>>> if eclipse is not longer supported in the trunk then the .project and
>>>>> .classpath should be removed.
>>>>> also I think that a vote should be done on removing Eclipse.
>>>>> However that will effect many who develop with eclipse.
>>>>> so it should be removed till a fix is found.
>>>>>
>>>>>
>>>>> Adam Heath sent the following on 10/30/2008 2:01 PM:
>>>>>> BJ Freeman wrote:
>>>>>>> i should clarify that ant build works
>>>>>>> but build thru eclipse does not
>>>>>>
>>>>>> Then how does eclipse call ant?  If the classloader it uses to
>>>>>> call ant
>>>>>> only has a small part of ant's optional libs, then there is
>>>>>> nothing more
>>>>>> we can do.  The classpath eclipse uses to call ant needs to be fixed.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>