Thanks for the input, Stefan. I took your suggestion and exposed a API
to get the Project on that custom interface. It doesn't/can't directly
use the IntrospectionHelper support available to project components,
since unlike nested elements of a task, this custom class can be plugged
in something like:
<listener
classname="some.custom.class.implementing.an.task.specific.interface"/>
plus the fact that this custom class can reside in a classloader defined
by nested <classpath> elements of this task.
-Jaikiran
On 13/03/18 3:36 PM, Stefan Bodewig wrote:
On 2018-03-13, Jaikiran Pai wrote:
I'm looking for some suggestion on whether it's a good/bad idea to
expose a method to custom user defined classes which takes a "Task"
object. This is in context of the JUnitLauncher task that I recently
added. It allows custom report formatters/listeners to be implemented
and the expectation is that such classes will implement the
TestResultFormatter interface that is (newly) part of Ant. This
interface exposes:
void setTask(Task currentExecutingTask)
so the implementations of this class have access to the current task
that's running. Right now, the only reason I exposed that Task
instance was to allow such implementation to issue log messages from
within the implementation like:
In that case I'd prefer the formatter implementation to extend
ProjectConponent or just provide a setProject(Project) method.
When your formatter is created by Ant - for example as a nested element
- something like
public void addConfiguredFormatter(TestFormatter f)
then IntrospectionHelper will see the setProject method and invoke it
with a reference to the current project.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
