User implementations of custom interfaces can have access to Task instance?

[Jaikiran Pai <ja...@gmail.com>]

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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: User implementations of custom interfaces can have access to Task instance?

[Stefan Bodewig <bo...@apache.org>]

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:

> <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.

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 <condition> task accepting arbitrary Condition
  implementations.

  You may consider using

      public void addConfigured(ListenerInterface l) { ... }

  in your task and

      <typedef name="customListener"
               classname="some.custom.class.implementing.an.task.specific.interface"/>
      <junitlauncher ...>
        <cusomListener/>
      </junitlauncher>

   in the build file. You'd even get classloader support for free.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: User implementations of custom interfaces can have access to Task instance?

[Jaikiran Pai <ja...@gmail.com>]

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-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org

Re: User implementations of custom interfaces can have access to Task instance?

[Stefan Bodewig <bo...@apache.org>]

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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org