Re: User implementations of custom interfaces can have access to Task instance?
On 2018-03-17, Jaikiran Pai wrote:
> 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:
> classname="some.custom.class.implementing.an.task.specific.interface"/>
> plus the fact that this custom class can reside in a classloader
> defined by nested elements of this task.
Just a few remarks, do with them however you see fit :-)
* you can use part of IntrospectionHelper's infrastructure, of
course. At least Project#setProjectReference so you don't have to
reinvent the reflrection logic.
* Your approach for listeners is that of the original JUnit task and
predates support for typedef together with
public void add(SomeInterface child);
for nested elements. Later we would have used the newer approach (see
for example the task accepting arbitrary Condition
implementations.
You may consider using
public void addConfigured(ListenerInterface l) { ... }
in your task and
in the build file. You'd even get classloader support for free.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: User implementations of custom interfaces can have access to Task instance?
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: classname="some.custom.class.implementing.an.task.specific.interface"/> plus the fact that this custom class can reside in a classloader defined by nested 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
Re: User implementations of custom interfaces can have access to Task instance?
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
User implementations of custom interfaces can have access to Task instance?
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: task.getProject().log(, level); I have been looking into other such cases where we allow custom implementations and documentation, but haven't found a guideline or anything that says whether it's good idea to give access to the Task instance to such custom implementations. For now, I would like to avoid it if possible (logging is the only reason I use this instance for now). However, if there are no real concerns of letting custom implementations of the interface have access to this, then I will just go ahead and expose it without worrying about it. P.S: I realize in fork mode, the Task instance won't be available and I'll be taking that into account, but this question is more a general guideline I'm looking for. -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
