junitlauncher task - support for system properties in a non-forked execution

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

junitlauncher task - support for system properties in a non-forked execution

Jaikiran Pai-2
While working on the documentation of the junitlauncher task, for fork
support, I realized that when we first released this task, due to an
oversight, I did not add support for setting system properties or
environment variables through this task. The fork element now supports
that[1] in the upcoming release, so that the forked JVM can be
configured with system properties and/or environment variables.

I am thinking of adding this support for even non-forked execution, like
junit task does. However, I would like some inputs on whether such
support for setting the system properties in a non-forked execution
should be at the junitlauncher task level or whether it should be
configured within each <test> and <testclasses> level. Or should we
allow it to configured at the task level as well as the individual
<test>/<testclasses> level?

junit task currently does it only at the task level.

[1]
https://github.com/apache/ant/commit/ffb80b688a12d4e60ab4be466ec0b3e396bb0078

-Jaikiran



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: junitlauncher task - support for system properties in a non-forked execution

Stefan Bodewig
On 2018-08-16, Jaikiran Pai wrote:

> While working on the documentation of the junitlauncher task, for fork
> support, I realized that when we first released this task, due to an
> oversight, I did not add support for setting system properties or
> environment variables through this task. The fork element now supports
> that[1] in the upcoming release, so that the forked JVM can be
> configured with system properties and/or environment variables.

> I am thinking of adding this support for even non-forked execution, like
> junit task does.

I'm not really sure people actually really use overwritten system
properties in non-forked mode, you might want to wait for people asking
for that feature.

> However, I would like some inputs on whether such support for setting
> the system properties in a non-forked execution should be at the
> junitlauncher task level or whether it should be configured within
> each <test> and <testclasses> level. Or should we allow it to
> configured at the task level as well as the individual
> <test>/<testclasses> level?

> junit task currently does it only at the task level.

If you really need to have different env variables for different tests
then I think the effort of configuring this properly isn't much less
than having to configure two instances of the junitlaucher task. IMHO
setting them at the task level should be enough, at least until anybody
makes a good case for more granular control.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: junitlauncher task - support for system properties in a non-forked execution

Jaikiran Pai-2
Hi Stefan,


On 22/08/18 12:00 AM, Stefan Bodewig wrote:

> On 2018-08-16, Jaikiran Pai wrote:
>
>> However, I would like some inputs on whether such support for setting
>> the system properties in a non-forked execution should be at the
>> junitlauncher task level or whether it should be configured within
>> each <test> and <testclasses> level. Or should we allow it to
>> configured at the task level as well as the individual
>> <test>/<testclasses> level?
>> junit task currently does it only at the task level.
> If you really need to have different env variables for different tests
> then I think the effort of configuring this properly isn't much less
> than having to configure two instances of the junitlaucher task. IMHO
> setting them at the task level should be enough, at least until anybody
> makes a good case for more granular control.

That's a good point. I think that will also make the implementation of
this task much simpler.

I won't add the sysproperty support for non-forked mode now and let
users try it out in the forked mode. As you note, only if there's some
real usecase/request for supporting this in non-forked mode, I will
revisit the feature. Thank you for your inputs.

-Jaikiran


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]