Re: Ant support for users who use JUnit5

[Jaikiran Pai]

I just realized that the manual that I linked in my mail isn't 
accessible to everyone. So here's an alternative link to the same 
https://home.apache.org/~jaikiran/temp_workspace/manual/Tasks/junitlauncher.html


-Jaikiran


On 15/02/18 7:21 PM, Jaikiran Pai wrote:
I'm now done with the initial goals that I had in mind for this task. 
I've opened a PR[1] for review. I've included a manual for this task 
and it can be currently found here[2]. I would suggest reading the 
manual first, before reviewing the PR, since the manual will give an 
overall idea of what's being attempted with this task.


Except for the "fork" mode which is available in our existing junit 
task and which was was in the TODO list, in my previous mail, the rest 
have been implemented in this version. I plan to focus on the "fork" 
mode after this task is made available to users and any feedback 
received.


I have tried to address some of the (internal) technicalities, based 
on some discussions that I have seen about JUnit, XML reporter and 
such, are around OOMs issues when it comes to sysout and syserr 
handling. Result formatters, which can be configured as listeners, are 
allowed to say "sendSysOut" and/or "sendSysErr". In such cases, the 
task will (internally) redirect the sysout/syserr to a 
PipedOutputStream (which is backed by a PipedInputStream). The task 
also sets up 2 separate threads - one which reads the PipedInputStream 
and "feeds" it to the second thread which "delivers" this content to 
such result formatters. The necessity to use a separate thread to 
deliver the content of sysout/syserr is so that we don't run into 
deadlocks (as noted in the Javadoc of Piped(output/input)Stream class) 
if/when the result formatters themselves write something out to 
sysout/syserr when they are working on this incoming sysout/syserr 
content.


We have 3 pre-defined formatters all of which are capable of receiving 
this streamed sysout/syserr data. Each of these do _not_ hold on to 
this sysout/syserr data in-memory during the execution and instead 
stream it out a temporary file. Once the execution completes and it's 
time to present the result, these formatters stream/read back the 
content from the temp file and write it out in a formatted manner to 
the target report files.


Furthermore, the XML formatter doesn't use DOM and instead is based on 
Stax for writing out the report. However, even with all this, there's 
one place where I haven't yet been able to avoid reading the whole 
generated sysout/syserr data into memory (thus potentially triggering 
an OOM) - it's the XMLStreamWriter API which for writing out a CDATA 
section (which is what we use for sysout/syserr content) in XML, 
expects the entire String object. I'll have to see if there are ways 
to avoid it, but I think this still is an improvement since this 
loaded content is only held on for a short while in memory, during the 
report writing and will be immediately garbage collected once that's 
done.


Please review the PR - mostly the Ant specific constructs and 
implementation details.


[1] https://github.com/apache/ant/pull/60

[2] 
https://builds.apache.org/job/Ant-Build-Jaikiran/ws/manual/Tasks/junitlauncher.html


[3] 
https://github.com/apache/ant/pull/60/files#diff-f985f89ce4779eff2cdcf164d09d5396R308


-Jaikiran




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 

[GitHub] ant issue #61: Use the isEmpty method instead of comparing the value of size...

[jaikiran]

Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/61
  
Thank for you the PR. This is now merged



---

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

[GitHub] ant pull request #61: Use the isEmpty method instead of comparing the value ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ant/pull/61


---

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

[GitHub] ant issue #61: Use the isEmpty method instead of comparing the value of size...

[asfgit]

Github user asfgit commented on the issue:

https://github.com/apache/ant/pull/61
  

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/Ant%20Github-PR-Windows/42/



---

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

[GitHub] ant issue #61: Use the isEmpty method instead of comparing the value of size...

[asfgit]

Github user asfgit commented on the issue:

https://github.com/apache/ant/pull/61
  

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/Ant%20Github-PR-Linux/36/



---

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

[GitHub] ant issue #60: JUnit 5 support - A new junitlauncher task

[asfgit]

Github user asfgit commented on the issue:

https://github.com/apache/ant/pull/60
  

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/Ant%20Github-PR-Windows/41/



---

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

[GitHub] ant issue #61: Use the isEmpty method instead of comparing the value of size...

[jaikiran]

Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/61
  
retest this please


---

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

[GitHub] ant issue #60: JUnit 5 support - A new junitlauncher task

[jaikiran]

Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/60
  
retest this please


---

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

[GitHub] ant issue #61: Use the isEmpty method instead of comparing the value of size...

[jaikiran]

Github user jaikiran commented on the issue:

https://github.com/apache/ant/pull/61
  
this is ok to test


---

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

[GitHub] ant pull request #61: Use the isEmpty method instead of comparing the value ...

[reudismam]

GitHub user reudismam opened a pull request:

https://github.com/apache/ant/pull/61

Use the isEmpty method instead of comparing the value of size() to 0.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/reudismam/ant size

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant/pull/61.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #61


commit 25315d0c28cf81c8c23944d3f368c76c6da02ac2
Author: reudismam 
Date:   2018-02-15T17:30:25Z

Use the isEmpty method instead of comparing the value of size() to 0.




---

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

[GitHub] ant issue #61: Use the isEmpty method instead of comparing the value of size...

[asfgit]

Github user asfgit commented on the issue:

https://github.com/apache/ant/pull/61
  
Can one of the admins verify this patch?


---

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

[GitHub] ant issue #61: Use the isEmpty method instead of comparing the value of size...

[asfgit]

Github user asfgit commented on the issue:

https://github.com/apache/ant/pull/61
  
Can one of the admins verify this patch?


---

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

[GitHub] ant issue #58: Use StringBuilder instead of StringBuffer as it offers high p...

[reudismam]

Github user reudismam commented on the issue:

https://github.com/apache/ant/pull/58
  
Undo edits to src/main/org/apache/tools/ant/listener/MailLogger.java and 
src/main/org/apache/tools/ant/taskdefs/Parallel.java


---

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

Re: Ant support for users who use JUnit5

[Jaikiran Pai]

From a release point of view - I know we are currently sorting out some 
regressions and issues that have been uncovered by the latest release. 
So if it makes things easier from a stability point of view, we can wait 
to merge this only after we have done another release which addresses 
only the regressions that we have found in our latest releases.


-Jaikiran


On 15/02/18 7:21 PM, Jaikiran Pai wrote:
I'm now done with the initial goals that I had in mind for this task. 
I've opened a PR[1] for review. I've included a manual for this task 
and it can be currently found here[2]. I would suggest reading the 
manual first, before reviewing the PR, since the manual will give an 
overall idea of what's being attempted with this task.


Except for the "fork" mode which is available in our existing junit 
task and which was was in the TODO list, in my previous mail, the rest 
have been implemented in this version. I plan to focus on the "fork" 
mode after this task is made available to users and any feedback 
received.


I have tried to address some of the (internal) technicalities, based 
on some discussions that I have seen about JUnit, XML reporter and 
such, are around OOMs issues when it comes to sysout and syserr 
handling. Result formatters, which can be configured as listeners, are 
allowed to say "sendSysOut" and/or "sendSysErr". In such cases, the 
task will (internally) redirect the sysout/syserr to a 
PipedOutputStream (which is backed by a PipedInputStream). The task 
also sets up 2 separate threads - one which reads the PipedInputStream 
and "feeds" it to the second thread which "delivers" this content to 
such result formatters. The necessity to use a separate thread to 
deliver the content of sysout/syserr is so that we don't run into 
deadlocks (as noted in the Javadoc of Piped(output/input)Stream class) 
if/when the result formatters themselves write something out to 
sysout/syserr when they are working on this incoming sysout/syserr 
content.


We have 3 pre-defined formatters all of which are capable of receiving 
this streamed sysout/syserr data. Each of these do _not_ hold on to 
this sysout/syserr data in-memory during the execution and instead 
stream it out a temporary file. Once the execution completes and it's 
time to present the result, these formatters stream/read back the 
content from the temp file and write it out in a formatted manner to 
the target report files.


Furthermore, the XML formatter doesn't use DOM and instead is based on 
Stax for writing out the report. However, even with all this, there's 
one place where I haven't yet been able to avoid reading the whole 
generated sysout/syserr data into memory (thus potentially triggering 
an OOM) - it's the XMLStreamWriter API which for writing out a CDATA 
section (which is what we use for sysout/syserr content) in XML, 
expects the entire String object. I'll have to see if there are ways 
to avoid it, but I think this still is an improvement since this 
loaded content is only held on for a short while in memory, during the 
report writing and will be immediately garbage collected once that's 
done.


Please review the PR - mostly the Ant specific constructs and 
implementation details.


[1] https://github.com/apache/ant/pull/60

[2] 
https://builds.apache.org/job/Ant-Build-Jaikiran/ws/manual/Tasks/junitlauncher.html


[3] 
https://github.com/apache/ant/pull/60/files#diff-f985f89ce4779eff2cdcf164d09d5396R308


-Jaikiran




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 

Re: Ant support for users who use JUnit5

[Jaikiran Pai]

I'm now done with the initial goals that I had in mind for this task. 
I've opened a PR[1] for review. I've included a manual for this task and 
it can be currently found here[2]. I would suggest reading the manual 
first, before reviewing the PR, since the manual will give an overall 
idea of what's being attempted with this task.


Except for the "fork" mode which is available in our existing junit task 
and which was was in the TODO list, in my previous mail, the rest have 
been implemented in this version. I plan to focus on the "fork" mode 
after this task is made available to users and any feedback received.


I have tried to address some of the (internal) technicalities, based on 
some discussions that I have seen about JUnit, XML reporter and such, 
are around OOMs issues when it comes to sysout and syserr handling. 
Result formatters, which can be configured as listeners, are allowed to 
say "sendSysOut" and/or "sendSysErr". In such cases, the task will 
(internally) redirect the sysout/syserr to a PipedOutputStream (which is 
backed by a PipedInputStream). The task also sets up 2 separate threads 
- one which reads the PipedInputStream and "feeds" it to the second 
thread which "delivers" this content to such result formatters. The 
necessity to use a separate thread to deliver the content of 
sysout/syserr is so that we don't run into deadlocks (as noted in the 
Javadoc of Piped(output/input)Stream class) if/when the result 
formatters themselves write something out to sysout/syserr when they are 
working on this incoming sysout/syserr content.


We have 3 pre-defined formatters all of which are capable of receiving 
this streamed sysout/syserr data. Each of these do _not_ hold on to this 
sysout/syserr data in-memory during the execution and instead stream it 
out a temporary file. Once the execution completes and it's time to 
present the result, these formatters stream/read back the content from 
the temp file and write it out in a formatted manner to the target 
report files.


Furthermore, the XML formatter doesn't use DOM and instead is based on 
Stax for writing out the report. However, even with all this, there's 
one place where I haven't yet been able to avoid reading the whole 
generated sysout/syserr data into memory (thus potentially triggering an 
OOM) - it's the XMLStreamWriter API which for writing out a CDATA 
section (which is what we use for sysout/syserr content) in XML, expects 
the entire String object. I'll have to see if there are ways to avoid 
it, but I think this still is an improvement since this loaded content 
is only held on for a short while in memory, during the report writing 
and will be immediately garbage collected once that's done.


Please review the PR - mostly the Ant specific constructs and 
implementation details.


[1] https://github.com/apache/ant/pull/60

[2] 
https://builds.apache.org/job/Ant-Build-Jaikiran/ws/manual/Tasks/junitlauncher.html


[3] 
https://github.com/apache/ant/pull/60/files#diff-f985f89ce4779eff2cdcf164d09d5396R308


-Jaikiran




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 

[GitHub] ant issue #60: JUnit 5 support - A new junitlauncher task

[asfgit]

Github user asfgit commented on the issue:

https://github.com/apache/ant/pull/60
  

Refer to this link for build results (access rights to CI server needed): 
https://builds.apache.org/job/Ant%20Github-PR-Linux/34/



---

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

[GitHub] ant pull request #60: JUnit 5 support - A new junitlauncher task

[jaikiran]

GitHub user jaikiran opened a pull request:

https://github.com/apache/ant/pull/60

JUnit 5 support - A new junitlauncher task

This is the initial working version of a new `junitlauncher` task that 
support using JUnit 5 framework for testing, within Ant build files. The commit 
in this PR is the initial set of goals that I had in mind for the first release 
of this task.

The manual for this task can be (temporarily) found at 
https://builds.apache.org/job/Ant-Build-Jaikiran/ws/manual/Tasks/junitlauncher.html

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jaikiran/ant junit5

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant/pull/60.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #60


commit 991bddff07b4fed1db2dc7f6b83f47557e62213b
Author: Jaikiran Pai 
Date:   2017-12-13T13:37:41Z

JUnit 5 support - A new junitlauncher task




---

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