ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaikiran Pai <>
Subject Re: Ant support for users who use JUnit5
Date Sat, 27 Jan 2018 03:18:07 GMT
One minor but important detail - this feature/task will only be 
available in the 1.10.x releases (whichever release we decide to include 
this in) and won't be available in 1.9.x releases of Ant.


On 27/01/18 8:40 AM, Jaikiran Pai wrote:
> Here's an update on where this effort now stands. As of yesterday, I 
> have the basic minimal functionality that I had planned for this (new) 
> task ready. There are other enhancements that this task will need as 
> we go along but at this point, this should be usable.
> While working on this new task, I kept thinking whether it would make 
> more sense to just have this task as a separate project under the Ant 
> umbrella and have its own release/versioning cycle. Plus maybe a bit 
> of ease in building/testing it given that it won't need some of the 
> conditional logic that we do in Ant build itself when it comes to such 
> tasks. It did look like a good idea to separate it out but ultimately 
> I decided _not_ to do it mainly for the reason that I think it makes 
> more sense to have a task in Ant which allows users to write tests 
> (using a modern test framework) and test them, right out of the box of 
> an Ant installation. This first class experience, IMO, outweighs all 
> the other "advantages" that seem to come with having this as a 
> separate project.
> Coming to the task itself, the task is called "junitlauncher". In the 
> current state of this task[1], the following goals/features are 
> implemented and functional:
> - Ability to launch the JUnit 5 platform
> - Ability to specify a classpath to use for the launched tests
> - Ability to specify one or more single test classes that need to be 
> run as part of this launch
> - Ability to specify specific methods on these test classses that need 
> to be run as part of the launch
> - Ability to specify "batch tests" which essentially is a way to use 
> Ant's resource collections to pattern match files that should be 
> passed on to the JUnit platform to be evaluated and run as test cases.
> - Ability to specify "listeners" for tests. These listeners are 
> expected to implement (intentionally) JUnit platform's interface and 
> _not_ any of Ant's interfaces.
> - Test result formatters are implemented as "listeners". This task 
> comes with 2 (for now) implementations out of the box, "plain" and 
> "brief". The idea behind these 2 is the same as that of what we 
> current have with the "junit" task formatters.
> - Users can define custom formatters as "listeners" by specifying a 
> class which implements the JUnit's test listener plus (optionally) one 
> of Ant's own (new) custom interface. This custom interface will let 
> them have access to output stream to which they might want to write 
> out the results.
> (I might be missing a few more details, but these are the major 
> functional features. The manual that I plan to write, will have the 
> whole details)
> In its current state the task should be able to run both "vintage" 
> (JUnit 4.x) and "jupiter" (JUnit 5.x) based tests.
> TODO/enhancements for later (a few days/weeks down the line):
> - Ability to "fork" these tests in a separate JVM. I haven't fully 
> thought about this and might need some inputs on whether we need this 
> or not. If we do add this, I might do it slightly differently that 
> what we current do with "junit" where there are numerous attributes to 
> the task/test elements which are only applicable if fork mode is 
> enabled. I might perhaps just introduce a new element within the 
> task's element which specifically is meant to deal with any forked VM 
> characteristics. But that's something I will get to after the other 
> easier enhancements are done.
> - Provide the XML formatter out of the box. I was planning to do this 
> in the first version itself, but I haven't had enough time to 
> understand the schema of this XML plus whether or not the details that 
> we put in here are available through the new JUnit launcher APIs.
> - Ability to more specifically say which JUnit test engine needs to be 
> used for the tests. Right now, the classpath decides which engine gets 
> used and thus which classes are considered as tests. If the classpath 
> has both "vintage" and "jupiter" engines then such tests will be run. 
> However, I want users to be able to say "just use jupiter engine for 
> these tests" without having to worry about checking if the classpath 
> is polluted with some other engines.
> - Make the current "junitreport" task be usable with the XML results 
> of this "junitlauncher" task. I haven't yet got to this but this 
> should be doable I think, of course once the XML formatter itself is 
> ready and functional. I don't plan to introduce a new task for this 
> and instead plan to reuse/enhance the existing junitreport task to 
> work seamlessly both with existing "junit" task and the 
> "junitlauncher" task.
> (Few other minor enhancements here and there and any user feedback 
> reports)
> For those of you curious to see what the task usage is going to look 
> like, here's an example[2] build file which shows its many usages. 
> That file will be cleaned up a bit, before I send a PR for review/merge.
> [1]
> [2] 
> -Jaikiran
> On 14/12/17 5:14 PM, Stefan Bodewig wrote:
>> On 2017-12-14, Jaikiran Pai wrote:
>>> With that context, I would like to explain what I have attempted so
>>> far and I would like inputs on whether I should follow this path
>>> and/or if there are other suggestions on how we should go ahead. As
>>> you are probably aware, the JUnitTask (the Ant task backing the
>>> <junit> element) has very complex logic which deals with launching the
>>> test runners responsible for running JUnit tests (3.x or 4.x). IMO,
>>> most this logic can now be handed off to the JUnit 5 platform
>>> launcher, using their APIs.
>> In addition some of the complexity inside of JUnitTask stems from the
>> fact that it must not refer to any JUnit 4.x API in order to be usable
>> in a pure JUnit 3.x environment. If you try to add JUnit 5 on top of
>> that this sounds diffciult.
>> I too had toyed with the idea of adding JUnit5 support but it is quite a
>> bit further down my TODO list and I've not looked into JUnit5 as deeply
>> as you did. What you've got so far looks promising, please please push
>> ahead.
>> My idea was to create a completely new task and mainly try to keep the
>> XML output the way it has been for some fifteen years so junitreport
>> would still work. I even though about placing it in a separate antlib
>> rather than Ant's core to allow it get released independently.
>> My vote would go to a separate task.
>> Stefan
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message