[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ant-dev] Testing Ant in a target workspace
|
Jared,
I appreciate that you have other stuff to focus on right now. I am willing
to look at the classloader/PDE/testing issues you are encountering if you
can point me at the relevant information. The only relevant bug report I
could find was http://dev.eclipse.org/bugs/show_bug.cgi?id=24049. Any
background you could supply would be useful.
Jeff
Jared Burns
<jared-eclipse@xxxxxxxx To: platform-ant-dev@xxxxxxxxxxx
m> cc:
Sent by: Subject: Re: [platform-ant-dev] Testing Ant in a
platform-ant-dev-admin@ target workspace
eclipse.org
09/30/2002 10:40 PM
Please respond to
platform-ant-dev
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
_______________________________________________
platform-ant-dev mailing list
platform-ant-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ant-dev
