Re: Cutting new releases?

[Jaikiran Pai]

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

[Jaikiran Pai]

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

[Jaikiran Pai]

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] 

Re: Cutting new releases?

[Jaikiran Pai]

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

[Gintautas Grigelionis]

Please upvote https://www.jfrog.com/jira/browse/RTFACT-15708

Gintas

Re: Cutting new releases?

[Gintautas Grigelionis]

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?

[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

Cutting new releases?

[Stefan Bodewig]

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

[reudismam]

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

[bodewig]

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

[asfgit]

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