Re: cvs commit: jakarta-cactus/Eclipse-Plugin PLAN.txt

[Christopher Lenz]

Vincent Massol wrote:

But for the sake of the discussion, let's call our interface:

public interface IContainerProvider {
    void runAntScript();
}

hmm ... What it means in reality is that the core engine of the Cactus
plugin is the Ant script and the Eclipse java code is only the UI. That
would be fine to me if it works.

Okay, for getting the plugin off the ground, I'd consider that a good enough approach. But then, the plugin shouldn't have an external API, as there'd be nothing to extend.

If I'm understanding the situation correctly, the interface you

propose

would mix two basically different concerns: container interaction on

the

one side, and test execution on the other. Test execution, however,
could simply be delegated to the existing Eclipse JUnit Plugin. In fact,
the Cactus plugin would sort of 'decorate' the JUnit plugin by adding
the container interaction before and after the tests.

Yep! That's *exactly* what we have started doing. The Cactus plugin
extends the JUnit one.

That's the one point where I don't see the Ant approach working. Using Ant, you'd be triggering test execution through Ant's TestRunner. Instead, the TestRunner/Listeners/whatever set up by the Eclipse JUnit plugin should be used. But maybe I'm being dumb ;-)

In addition, the Eclipse JUnit plugin is not (yet) designed for being extended/decorated. Every class in the plugin is under org.eclipse.jdt.internal, meaning it's not an API that should be relied upon by third parties. Maybe the possibility of decorating/extending the Eclipse JUnit plugin should be discussed with the corresponding Eclipse team?

--
Christopher Lenz
/=/ cmlenz at gmx.de


--
To unsubscribe, e-mail: <mailto:cactus-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:cactus-dev-help@;jakarta.apache.org>