Re: Cutting new releases?
I just remembered - we probably have to investigate that image task test failure on Java 9 and see if its some setup issue or whether that task is genuinely broken against that runtime. I haven't yet found the time to dig deeper on that one. -Jaikiran On Friday, January 26, 2018, Stefan Bodewig wrote: > Hi all > > while merging the latest changes I've saw master is now more than 200 > commits ahead of the 1.10.1 tag, maybe it is time for a release. :-) > > I propose to cut 1.9.10 and 1.10.2 in parallel. > > Does anybody feel either of the two branches isn't stable enough or is > anybody currently working on/looking into soemthing that should delay > releases? > > Stefan > > - > 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
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. -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 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
Re: Ant support for users who use JUnit5
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] https://github.com/apache/ant/compare/master...jaikiran:junit5 [2] https://github.com/apache/ant/compare/master...jaikiran:junit5#diff-3e0911ed925129e68c543aca0abc5d7
Re: Cutting new releases?
On 26/01/18 11:15 PM, Stefan Bodewig wrote: Does anybody feel either of the two branches isn't stable enough or is anybody currently working on/looking into soemthing that should delay releases? I have been working on support for JUnit5 and incidentally was about to create a initial PR for review/merge this weekend. Here's[1] the first working version of it. Please review, I'll send an official PR soon. I have some cosmetic changes, javadocs and other things planned in there before we merge it, plus I want to add at least one test which tests against pure (a.k.a "jupiter" engine) JUnit 5 test case. The current added tests verify the new task against "vintage" JUnit tests, which are supported by JUnit 5. Plus of course, I have to create a manual for this task. I have explained this task and the plan/goals in more detail in the other thread in this list. As to whether this task should hold up the release is something that I will leave to Stefan and others to decide. Personally, I have no strong opinion on either way about this task making it to this release. However, my plan is to make this task available this weekend to an extent that it can be used for the basic minimal functionality and then keep adding anything more that we want in this task in future releases. More details about this are in the other thread. [1] https://github.com/apache/ant/compare/master...jaikiran:junit5 -Jaikiran - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Artifactory regression wrt Ivy
Please upvote https://www.jfrog.com/jira/browse/RTFACT-15708 Gintas
Re: Cutting new releases?
I'd love to ivyfy Ant (at least 1.10), but as I said elsewhere that would require Ivy 2.5 ;-) Gintas 2018-01-26 20:04 GMT+01:00 Jan Matèrne (jhm) : > Cool. ;) > Have committed my hint to the manual. > Nothing more in my pipeline ... > > Jan > > > -Ursprüngliche Nachricht- > > Von: Stefan Bodewig [mailto:bode...@apache.org] > > Gesendet: Freitag, 26. Januar 2018 18:45 > > An: dev@ant.apache.org > > Betreff: Cutting new releases? > > > > Hi all > > > > while merging the latest changes I've saw master is now more than 200 > > commits ahead of the 1.10.1 tag, maybe it is time for a release. :-) > > > > I propose to cut 1.9.10 and 1.10.2 in parallel. > > > > Does anybody feel either of the two branches isn't stable enough or is > > anybody currently working on/looking into soemthing that should delay > > releases? > > > > 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 > >
AW: Cutting new releases?
Cool. ;) Have committed my hint to the manual. Nothing more in my pipeline ... Jan > -Ursprüngliche Nachricht- > Von: Stefan Bodewig [mailto:bode...@apache.org] > Gesendet: Freitag, 26. Januar 2018 18:45 > An: dev@ant.apache.org > Betreff: Cutting new releases? > > Hi all > > while merging the latest changes I've saw master is now more than 200 > commits ahead of the 1.10.1 tag, maybe it is time for a release. :-) > > I propose to cut 1.9.10 and 1.10.2 in parallel. > > Does anybody feel either of the two branches isn't stable enough or is > anybody currently working on/looking into soemthing that should delay > releases? > > 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
Cutting new releases?
Hi all while merging the latest changes I've saw master is now more than 200 commits ahead of the 1.10.1 tag, maybe it is time for a release. :-) I propose to cut 1.9.10 and 1.10.2 in parallel. Does anybody feel either of the two branches isn't stable enough or is anybody currently working on/looking into soemthing that should delay releases? Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #55: Use valueOf method instead of constructor since valueOf has h...
Github user reudismam commented on the issue: https://github.com/apache/ant/pull/55 Thank you. Reudismam Rolim is good for me. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant issue #55: Use valueOf method instead of constructor since valueOf has h...
Github user bodewig commented on the issue: https://github.com/apache/ant/pull/55 Thanks @reudismam - is it OK with you if we add your name to the contributors file (and if so which would be the name you'd like to see)? --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant pull request #55: Use valueOf method instead of constructor since valueO...
Github user asfgit closed the pull request at: https://github.com/apache/ant/pull/55 --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org