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