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

[Adam Heath-2]

Jacques Le Roux wrote:
> BTW we can revert r709250 : it's useless

So you're saying the other ant jars that are already in .classpath are
useless too?  If so, then might as well remove them, because otherwise
it's confusing.

And if this is so, then it really does point to an eclipse configuration
issue, and not something that ofbiz can actually work with.

[Adrian Crum]

Adam,

Your commit doesn't fix the Eclipse issue. I have a fresh checkout and
I'm willing to help solve the problem.

Here are the ant jars listed in the classpath file, let me know what
order they should be in:

<classpathentry kind="lib"
path="framework/base/lib/ant/ant-nodeps-1.7.0.jar"/>
<classpathentry kind="lib"
path="framework/base/lib/ant/ant-apache-bsf-1.7.0.jar"/>
<classpathentry kind="lib"
path="framework/base/lib/ant-launcher-1.7.0.jar"/>
<classpathentry kind="lib" path="framework/base/lib/ant-1.7.0.jar"/>

-Adrian

Adam Heath wrote:

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

[Adam Heath-2]

Adrian Crum wrote:

> Your commit doesn't fix the Eclipse issue. I have a fresh checkout and
> I'm willing to help solve the problem.
>
> Here are the ant jars listed in the classpath file, let me know what
> order they should be in:
>
> <classpathentry kind="lib"
> path="framework/base/lib/ant/ant-nodeps-1.7.0.jar"/>
> <classpathentry kind="lib"
> path="framework/base/lib/ant/ant-apache-bsf-1.7.0.jar"/>
> <classpathentry kind="lib"
> path="framework/base/lib/ant-launcher-1.7.0.jar"/>
> <classpathentry kind="lib" path="framework/base/lib/ant-1.7.0.jar"/>

My guess is that any ant jar in .classpath is not used at all; eclipse
itself has it's one ant jars that is uses to start the build process.

As a test, remove those 4 entries, and try a build.  If it starts ant,
and fails in the exact same way, then it shows that it's not using our
own ant jars, but something else.  It also means something else inside
eclipse needs to be fixed to make this work.

Backing out my change from a few days ago is not the right thing to do
here; this probably would eventually come up at some point, so we might
as well go about seeing what needs to be done to fix it.

[Jacques Le Roux]

Not sure for those ones. The Preferences, Ant Runtime, "Ant Home' change is only to be able to run existing configurations.
It's clearly an Eclipse configuration issue but related to OFBiz : by default Eclipse comes with [Preferences, Ant Runtime, "Ant
Home' ] sets to the Eclipse embedded Ant plugin path.
So, by default, we are no longer Eclipse compatible, not a big deal... just another complication...

Jacques

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

> Jacques Le Roux wrote:
>> BTW we can revert r709250 : it's useless
>
> So you're saying the other ant jars that are already in .classpath are
> useless too?  If so, then might as well remove them, because otherwise
> it's confusing.
>
> And if this is so, then it really does point to an eclipse configuration
> issue, and not something that ofbiz can actually work with.
>

[Jacques Le Roux]

Yes, by default, Eclipse uses its embedded plugin (path set in [Preferences, Ant Runtime, "Ant Home" ])

Jacques

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

> Adrian Crum wrote:
>
>> Your commit doesn't fix the Eclipse issue. I have a fresh checkout and
>> I'm willing to help solve the problem.
>>
>> Here are the ant jars listed in the classpath file, let me know what
>> order they should be in:
>>
>> <classpathentry kind="lib"
>> path="framework/base/lib/ant/ant-nodeps-1.7.0.jar"/>
>> <classpathentry kind="lib"
>> path="framework/base/lib/ant/ant-apache-bsf-1.7.0.jar"/>
>> <classpathentry kind="lib"
>> path="framework/base/lib/ant-launcher-1.7.0.jar"/>
>> <classpathentry kind="lib" path="framework/base/lib/ant-1.7.0.jar"/>
>
> My guess is that any ant jar in .classpath is not used at all; eclipse
> itself has it's one ant jars that is uses to start the build process.
>
> As a test, remove those 4 entries, and try a build.  If it starts ant,
> and fails in the exact same way, then it shows that it's not using our
> own ant jars, but something else.  It also means something else inside
> eclipse needs to be fixed to make this work.
>
> Backing out my change from a few days ago is not the right thing to do
> here; this probably would eventually come up at some point, so we might
> as well go about seeing what needs to be done to fix it.
>

[Adam Heath-2]

Jacques Le Roux wrote:
> Not sure for those ones. The Preferences, Ant Runtime, "Ant Home' change
> is only to be able to run existing configurations.
> It's clearly an Eclipse configuration issue but related to OFBiz : by
> default Eclipse comes with [Preferences, Ant Runtime, "Ant Home' ] sets
> to the Eclipse embedded Ant plugin path.
> So, by default, we are no longer Eclipse compatible, not a big deal...
> just another complication...

Nononono, that's not the case.

Eclipse is not ant compatible.

Eclipse needs to support the optional ant tasks.  This has nothing to do
with ofbiz.  Any other project out there that makes use of those same
optional tasks is going to have the exact same set of problems.

[Adrian Crum]

I can't be sure, but I believe those are global preferences - so they
would be applied to all projects, not just OFBiz.

-Adrian

Jacques Le Roux wrote:

> Not sure for those ones. The Preferences, Ant Runtime, "Ant Home' change
> is only to be able to run existing configurations.
> It's clearly an Eclipse configuration issue but related to OFBiz : by
> default Eclipse comes with [Preferences, Ant Runtime, "Ant Home' ] sets
> to the Eclipse embedded Ant plugin path.
> So, by default, we are no longer Eclipse compatible, not a big deal...
> just another complication...
>
> Jacques
>
> From: "Adam Heath" <[hidden email]>
>> Jacques Le Roux wrote:
>>> BTW we can revert r709250 : it's useless
>>
>> So you're saying the other ant jars that are already in .classpath are
>> useless too?  If so, then might as well remove them, because otherwise
>> it's confusing.
>>
>> And if this is so, then it really does point to an eclipse configuration
>> issue, and not something that ofbiz can actually work with.
>>
>
>

[Adrian Crum]

As Jacques mentioned, your guess is right. Eclipse insists on using its
own copy of Ant - even when you try to change the preferences. I tried
creating my own project-specific Builder, but that didn't work either.

I tried, but I couldn't get it to work. Can I have a cookie anyway?

-Adrian

Adam Heath wrote:

> Adrian Crum wrote:
>
>> Your commit doesn't fix the Eclipse issue. I have a fresh checkout and
>> I'm willing to help solve the problem.
>>
>> Here are the ant jars listed in the classpath file, let me know what
>> order they should be in:
>>
>> <classpathentry kind="lib"
>> path="framework/base/lib/ant/ant-nodeps-1.7.0.jar"/>
>> <classpathentry kind="lib"
>> path="framework/base/lib/ant/ant-apache-bsf-1.7.0.jar"/>
>> <classpathentry kind="lib"
>> path="framework/base/lib/ant-launcher-1.7.0.jar"/>
>> <classpathentry kind="lib" path="framework/base/lib/ant-1.7.0.jar"/>
>
> My guess is that any ant jar in .classpath is not used at all; eclipse
> itself has it's one ant jars that is uses to start the build process.
>
> As a test, remove those 4 entries, and try a build.  If it starts ant,
> and fails in the exact same way, then it shows that it's not using our
> own ant jars, but something else.  It also means something else inside
> eclipse needs to be fixed to make this work.
>
> Backing out my change from a few days ago is not the right thing to do
> here; this probably would eventually come up at some point, so we might
> as well go about seeing what needs to be done to fix it.
>

[BJ Freeman]

the point is not that it would come up, but that it would not cause a
glitch.
by backing out you changes, it would give a chance to find a solution
without disrupting development environments.

once everyone is on board with the changes, which may include a upgrade
of eclipse, then put them back in.



Adam Heath sent the following on 10/30/2008 3:18 PM:
> Backing out my change from a few days ago is not the right thing to do
> here; this probably would eventually come up at some point, so we might
> as well go about seeing what needs to be done to fix it.
>
>

[Jacques Le Roux]

Then one (maybe temporary) solution would be to set this only project by project.
In my case it should not be a problem to have it using OFBiz ant for any project anyway so the global configuration is ok for me

Jacques

From: "Adrian Crum" <[hidden email]>

>I can't be sure, but I believe those are global preferences - so they
> would be applied to all projects, not just OFBiz.
>
> -Adrian
>
> Jacques Le Roux wrote:
>> Not sure for those ones. The Preferences, Ant Runtime, "Ant Home' change
>> is only to be able to run existing configurations.
>> It's clearly an Eclipse configuration issue but related to OFBiz : by
>> default Eclipse comes with [Preferences, Ant Runtime, "Ant Home' ] sets
>> to the Eclipse embedded Ant plugin path.
>> So, by default, we are no longer Eclipse compatible, not a big deal...
>> just another complication...
>>
>> Jacques
>>
>> From: "Adam Heath" <[hidden email]>
>>> Jacques Le Roux wrote:
>>>> BTW we can revert r709250 : it's useless
>>>
>>> So you're saying the other ant jars that are already in .classpath are
>>> useless too?  If so, then might as well remove them, because otherwise
>>> it's confusing.
>>>
>>> And if this is so, then it really does point to an eclipse configuration
>>> issue, and not something that ofbiz can actually work with.
>>>
>>
>>
>

[Jacques Le Roux]

Forget it, it's not accessible on a project basis (no Ant preferences by project). So it's by configuration or global

Jacques

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

> Then one (maybe temporary) solution would be to set this only project by project.
> In my case it should not be a problem to have it using OFBiz ant for any project anyway so the global configuration is ok for me
>
> Jacques
>
> From: "Adrian Crum" <[hidden email]>
>>I can't be sure, but I believe those are global preferences - so they
>> would be applied to all projects, not just OFBiz.
>>
>> -Adrian
>>
>> Jacques Le Roux wrote:
>>> Not sure for those ones. The Preferences, Ant Runtime, "Ant Home' change
>>> is only to be able to run existing configurations.
>>> It's clearly an Eclipse configuration issue but related to OFBiz : by
>>> default Eclipse comes with [Preferences, Ant Runtime, "Ant Home' ] sets
>>> to the Eclipse embedded Ant plugin path.
>>> So, by default, we are no longer Eclipse compatible, not a big deal...
>>> just another complication...
>>>
>>> Jacques
>>>
>>> From: "Adam Heath" <[hidden email]>
>>>> Jacques Le Roux wrote:
>>>>> BTW we can revert r709250 : it's useless
>>>>
>>>> So you're saying the other ant jars that are already in .classpath are
>>>> useless too?  If so, then might as well remove them, because otherwise
>>>> it's confusing.
>>>>
>>>> And if this is so, then it really does point to an eclipse configuration
>>>> issue, and not something that ofbiz can actually work with.
>>>>
>>>
>>>
>>
>

[Adam Heath-2]

BJ Freeman wrote:
> the point is not that it would come up, but that it would not cause a
> glitch.
> by backing out you changes, it would give a chance to find a solution
> without disrupting development environments.
>
> once everyone is on board with the changes, which may include a upgrade
> of eclipse, then put them back in.

Done, version 709292.  I'm going to have to get eclipse installed, and
see how to make it work.

I really wanted this stuff to work, as I need javacc/jjtree for a new
feature I've been working on for years, but I guess it'll have to wait.

[Adrian Crum]

Adam Heath wrote:
> Done, version 709292.  I'm going to have to get eclipse installed, and
> see how to make it work.

Or the Eclipse users can uncomment the script stuff and continue trying
to find a solution.

-Adrian

[Jacques Le Roux]

But it seems the only things to do is to put the jars needed by the optional tasks in the ant directory isn'it ?
So it's not really a bug, only a configuration problem.
Quickly :
Eclipse comes by defaut with an Ant plugin under something like eclipse/plugins/ant
A project uses specific Ant optional tasks which need specific jar
2 solutions :
    put the jars in eclipse/plugins/ant to avoid changing Eclipse Ant plugin default setting
    let the jars in the project and point Ant Home to the directory where the jars are

In both cases, now OFBiz needs a change in Eclipse to be able to run ant tasks

Jacques

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

> Jacques Le Roux wrote:
>> Not sure for those ones. The Preferences, Ant Runtime, "Ant Home' change
>> is only to be able to run existing configurations.
>> It's clearly an Eclipse configuration issue but related to OFBiz : by
>> default Eclipse comes with [Preferences, Ant Runtime, "Ant Home' ] sets
>> to the Eclipse embedded Ant plugin path.
>> So, by default, we are no longer Eclipse compatible, not a big deal...
>> just another complication...
>
> Nononono, that's not the case.
>
> Eclipse is not ant compatible.
>
> Eclipse needs to support the optional ant tasks.  This has nothing to do
> with ofbiz.  Any other project out there that makes use of those same
> optional tasks is going to have the exact same set of problems.
>

[Jacques Le Roux]

Simpler than the solutions proposed so far  :o)
One solution (to avoid any settings on our side) would be to request the Eclipse Ant plugin team to put the needed jars in their
directory.
Maybe there is already a mechanism to automatize that since from UI you are able to do it
Window --> Preferences, Ant --> Runtime. In the Classpath tab click on Global Entries and then Add External JARs....

Jacques

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

> BJ Freeman wrote:
>> the point is not that it would come up, but that it would not cause a
>> glitch.
>> by backing out you changes, it would give a chance to find a solution
>> without disrupting development environments.
>>
>> once everyone is on board with the changes, which may include a upgrade
>> of eclipse, then put them back in.
>
> Done, version 709292.  I'm going to have to get eclipse installed, and
> see how to make it work.
>
> I really wanted this stuff to work, as I need javacc/jjtree for a new
> feature I've been working on for years, but I guess it'll have to wait.
>

[Scott Gray]

As far as I can see there is now way to specify ANT_HOME in a way that
we could put into svn.  I don't think it is a big deal to create a
confluence page showing users how to change ANT_HOME per build launch
or globally and I think most other projects do just that.

Regards
Scott

2008/10/31 Adrian Crum <[hidden email]>:

> Adam Heath wrote:
>>
>> Done, version 709292.  I'm going to have to get eclipse installed, and
>> see how to make it work.
>
> Or the Eclipse users can uncomment the script stuff and continue trying to
> find a solution.
>
> -Adrian
>
>
>

[Jacques Le Roux]

I finally agree, sound reasonnable enough and would allow Adam to continue his work
Maybe a vote ?

Jacques
PS : except if, as I already suggested, there is a solution in Ant plugin itself (to be checked)

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

> As far as I can see there is now way to specify ANT_HOME in a way that
> we could put into svn.  I don't think it is a big deal to create a
> confluence page showing users how to change ANT_HOME per build launch
> or globally and I think most other projects do just that.
>
> Regards
> Scott
>
> 2008/10/31 Adrian Crum <[hidden email]>:
>> Adam Heath wrote:
>>>
>>> Done, version 709292.  I'm going to have to get eclipse installed, and
>>> see how to make it work.
>>
>> Or the Eclipse users can uncomment the script stuff and continue trying to
>> find a solution.
>>
>> -Adrian
>>
>>
>>
>

[Adam Heath-2]

Jacques Le Roux wrote:
> I finally agree, sound reasonnable enough and would allow Adam to
> continue his work
> Maybe a vote ?

Since I'm the only one who needs/wants this stuff, I should be the one
that has to maintain a local-only change.

[Jacques Le Roux]

Even more reasonnable, but dit you not intend to make the community take advantage of your changes ?

Jacques

From: "Adam Heath" <[hidden email]>
> Jacques Le Roux wrote:
>> I finally agree, sound reasonnable enough and would allow Adam to
>> continue his work
>> Maybe a vote ?
>
> Since I'm the only one who needs/wants this stuff, I should be the one
> that has to maintain a local-only change.
>

[Adam Heath-2]

Jacques Le Roux wrote:
> Even more reasonnable, but dit you not intend to make the community take
> advantage of your changes ?

Sure, but it might be premature.  Was hoping to have this basic stuff
working for the conference, but might have to push back a bit.  There's
still time for me to figure out what I'm going to do.