Re: [platform-ant-dev] Testing Ant in a target workspace

[Jared Burns <jared-eclipse@xxxxxxxxx>]

This perversion is required because of a plugin classloader problem that 
occurs when trying to run Ant in a selfhosting Eclipse environment. We end up 
with a class (the Ant console, I believe) loaded in two separate 
classloaders. This screws up static variables and causes problems.

You don't need to convince us about PDE. Until we started working on Ant, we 
both selfhosted using PDE like everyone else. We hope that the  
"updateTarget" dance is only a temporary workaround until we have time to 
examine the problem closer and find a "real" (PDE friendly) solution. The Ant 
tooling (the UI, at least) is currently in a near-crisis state (that is, it 
doesn't work) so we don't have time to devote to solving meta problems like 
this one.

Since Ant doesn't work with normal PDE selfhosting, we assumed that the 
previous maintainers had used a similar approach for testing/debugging Ant. 
Is this not the case?

- Jared

On Monday 30 September 2002 08:43 pm, you wrote:
> Darin, this is useful information but it raises a few questions.  Why don't
> you just use PDE to do this?  I know there is code there to do most/all of
> what your scripts do.  Perhaps PDE needs to have an Ant task or two
> provided?  There are two reasons this is important.
>
> First, this kind of approach is error prone.  If something changes in the
> build.properties file, the updateTarget.xml file must also be updated.
>
> The second is that for most/many people, PDE is the tool to use for
> developing plugins.  If it does not serve the needs of those people then it
> should be fixed.  The best people to find/fix the deficiencies are the
> eclipse team itself.  To that end, I would encourage people to use PDE and
> complain if it does not do what they need/want.
>
> MetaMoment:  I'm not quite sure of the usecase for what you are doing.  If
> it is ongoing testing of changes then one should be able to skip all of
> this and just run with "-dev bin" on the target's command line.   Much
> lighterweight.  If you want to be sure you are running "the real thing"
> then PDE should do the trick as it generates exactly what is shipped (note
> for the anally retentive like me: updateTarget.xml generates a plugin dir
> which has more than the real build plugin).
>
> Either way, if people are finding that they really have to do it this way
> then something is broken in our tooling.
>
> Jeff