Hi, Unfortunately support for JUnit5 in Apache Ant still seems to be a bit rough with some problems and some things missing/ongoing. The whole approach with forward/capturing sysout/syserr felt flaky and error-prone when I took a look in December.
For now we can only try to help the Ant Guys push out fixes or duplicate some fixed code for the result listeners into our code-base like Andi tried already, but this may introduce it's own set of problems with different versions of Ant. In the long run switching to a full Gradle build would be nice and would base our build on a fully supported build tool, but would need quite some work as the current approach to map the source-directories for the Gradle build is also clumsy and error-prone and would need a major overhaul... Dominik. On Tue, Feb 9, 2021 at 12:34 PM Marius Volkhart <[email protected]> wrote: > Hello, > > I think I'm running into a reported deadlock in Ant when running the > integration tests with the Log4J logging code. > https://bz.apache.org/bugzilla/show_bug.cgi?id=64733 > > When I include either of the legacy result listeners, Ant hangs. When I > remove them however, everything passes. This looks to be happening on > Jenkins, GitHub Actions, and on my dev machine. > > I'm puzzled as to what to try next. > > -- > Cheers, > Marius > > > On 2020/12/23 19:09:27, Andreas Beeker <[email protected]> wrote: > > Hi Devs,> > > > > I've finished the migration to Junit5 for the ant target.> > > I'm now focusing on the maven builds, but I don't expect problems with > the surefire plugin.> > > > > The following changes will be visible after I committed the 1000+ file > changes:> > > > > a) Junit5 uses different annotations and different packages> > > > > b) expected exceptions are now handled via assertThrows> > > > > c) ant lacks support for direct test feedback - see > https://bz.apache.org/bugzilla/show_bug.cgi?id=64836> > > I'm using a custom test listener to print the summary, but this will > only be shown when all tests of the current module are processed> > > > > d) JaCoCo is not handling Junit5 in the "coverage" tag - see > https://github.com/jacoco/jacoco/issues/673> > > I've worked around it with the "agent" tag, but I haven't test it yet> > > > > e) I've deleted all TestSuites (like AllFormulaTests) locally, as the > described annotations weren't found.> > > now that I have all the junit plattform dependencies available, I > might revert/migrate those to the Junit5 - see > https://howtodoinjava.com/junit5/junit5-test-suites-examples/> > > > > Now (i.e. before I commit the tests) would be a good time to give me your > two pence.> > > > > > > Background info:> > > it all started when I've seen the migration wizard in IntelliJ and > thought, it might be a piece of cake to convert our tests.> > > But 3-5 days later after cumbersome copy&pasting the test comment from > the left to the right of assertEquals(<comment>, ...), I've realized that I > could have done it more efficiently with IntelliJs structural search > replacement.> > > After fixing all the compile errors, I've realized that various tools > (ant, junitlauncher, JaCoCo) might have also some homework to do with > Junit5. But after spending/wasting so much time, I'm reluctant to go back > to Junit4 just because we might have a problem with the gradle builds > (which I probably don't convert) ... you probably know that psychological > effect, that given a certain amount of time(/money) spent, one is unable to > reflect and go back ... just like with our airport in Berlin ...> > > In general I would say the move to Junit5 makes sense, as this is were > the current development of the junit team takes place, even when we > discover a few more bumps.> > > > > Andi> > > > > > > ---------------------------------------------------------------------> > > To unsubscribe, e-mail: [email protected]> > > For additional commands, e-mail: [email protected]> > > > > >
