[GitHub] [ant] azotcsit commented on a change in pull request #175: junitlauncher - Fix an issue in LegacyXmlResultFormatter with ]]> in stacktraces

[GitBox]

azotcsit commented on a change in pull request #175:
URL: https://github.com/apache/ant/pull/175#discussion_r789921289



##
File path: 
src/main/org/apache/tools/ant/taskdefs/optional/junitlauncher/LegacyXmlResultFormatter.java
##
@@ -298,8 +298,9 @@ private void writeFailed(final XMLStreamWriter writer, 
final TestIdentifier test
 writeAttribute(writer, ATTR_MESSAGE, message);
 }
 writeAttribute(writer, ATTR_TYPE, t.getClass().getName());
-// write out the stacktrace
-writer.writeCData(StringUtils.getStackTrace(t));
+// write out the stacktrace, replacing any CDATA endings by 
splitting them into multiple CDATA segments
+// See https://bz.apache.org/bugzilla/show_bug.cgi?id=65833
+
writer.writeCData(StringUtils.getStackTrace(t).replaceAll("]]>", 

Re: [DISCUSS] JUnit 5 Customization

[Aleksei Zotov]

Hi Jaikiran,

Were you able to check the PRs? I'd would be great to get into the next
release with these changes (or alternative workarounds), so we (Apache
Cassandra) can move forward with JUnit 5 upgrade.


Best Regards,

Aleksei Zotov.


On Thu, Dec 23, 2021 at 5:22 PM Aleksei Zotov  wrote:

> Jaikiran,
>
> Thank you for the quick response!
>
> ant -f fetch.xml -Ddest=optional
>
> It helped, thanks for pointing this out!
>
> I can understand that some of the code in the AbstractJUnitResultFormatter
>> might appear reusable and would be tempting to reuse/extend, but I wouldn't
>> want anything outside of Ant to start using these classes and instead just
>> code against the JUnit5 classes/interfaces.
>
> Having said all this, if any of other maintainers of the Ant project feel
>> that we should allow these internal classes to be extensible, I won't mind
>> having this work reviewed and merged.
>
> I truly understand your point of view. If no-one else needs this
> functionality we'll simply implement custom formatters/listeners based on
> the existing implementation in *ant* project.
>
> I'll take a look at this one.
>
> Great, thanks.
>
>
> Best Regards,
>
> Aleksei Zotov.
>
>
> On Thu, Dec 23, 2021 at 6:34 AM Jaikiran Pai 
> wrote:
>
>> Hello Aleksei,
>>
>> On 22/12/21 7:59 pm, Aleksei Zotov wrote:
>> > Hi Ant Developers,
>> >
>> > I'm working on the migration of Apache Cassandra project from JUnit 4 to
>> > JUnit 5 (CASSANDRA-16630
>> > ) which turned
>> out
>> > to be larger than I originally expected. At the moment, three PRs got
>> > merged:
>> >
>> > - https://github.com/apache/ant/pull/147
>> > - https://github.com/apache/ant/pull/168
>> > - https://github.com/apache/ant/pull/172
>> >
>> > And there are a few more I'd like to discuss with you.
>>
>> Sorry, I remember seeing a PR from you where you asked for some inputs
>> in this area, but I haven't been able to get to it due to some other
>> priorities.
>>
>> >
>> > Formatters Extensibility
>> > Apache Cassandra extended the existing JUnit 4 formatters in order to
>> > integrate them with a custom logic required for a better CI process. It
>> was
>> > easily achievable for JUnit 4 since the formatters are marked public. On
>> > the contrary, for JUnit 5 all formatters are package private. Even
>> > *AbstractJUnitResultFormatter* is package private. Of course, we can
>> > copy-paste all these classes to our project and customize them based on
>> our
>> > needs, but that seems to be a bit of an overhead.
>> >
>> > Currently, we'd like to make *AbstractJUnitResultFormatter *extensible.
>> > Here is the corresponding PR: https://github.com/apache/ant/pull/169/
>>
>> The reason why these formatters are package private and not extensible
>> is intentional. When I added these formatters, one of the goals of these
>> formatters was to only make them generate output to an extent that it
>> matches the JUnit4 style formatters of the "junit" task (hence the name
>> "legacy-" to those formatters). All these pre-shipped "legacy-"
>> listeners that you see in Ant are only there for minimal support and
>> their implementation is considered to be internal to the Ant distribution.
>>
>> The new JUnit5 framework itself is extensible and also comes with some
>> pre-shipped "listeners" (implementations of TestExecutionListener).
>> That's one of the reasons why the junitlauncher task's "listener"
>> element provides a direct way to use any implementation of the JUnit5
>> framework's "org.junit.platform.launcher.TestExecutionListener". i.e.
>> for any code that seeks extensibility, the
>> org.junit.platform.launcher.TestExecutionListener is expected to be the
>> extension point/interface and not Ant's internal
>> AbstractJUnitResultFormatter. This allows the junitlauncher task to be
>> minimal and allows it to achieve its goal of just being something that
>> will launch the JUnit5 framework.
>>
>> I can understand that some of the code in the
>> AbstractJUnitResultFormatter might appear reusable and would be tempting
>> to reuse/extend, but I wouldn't want anything outside of Ant to start
>> using these classes and instead just code against the JUnit5
>> classes/interfaces.
>>
>> Having said all this, if any of other maintainers of the Ant project
>> feel that we should allow these internal classes to be extensible, I
>> won't mind having this work reviewed and merged.
>>
>> > Fork Mode Support
>> > Apache Cassandra is a large and complex product and in order to
>> guarantee
>> > its quality we run many tests independently. It lets us ensure different
>> > test suites do not affect each other. For isolated testing we spin up a
>> new
>> > JVM per tests suite via *forkMode* property. Unfortunately,
>> > *junitlauncher* task
>> > does not provide such a functionality.
>> >
>> > Currently, we'd like *mode* attribute to *fork* element. Here is the
>> > corresponding PR: 

[GitHub] [ant] tsmock opened a new pull request #175: Fix an issue in LegacyXmlResultFormatter with ]]> in stacktraces

[GitBox]

tsmock opened a new pull request #175:
URL: https://github.com/apache/ant/pull/175


   Bugzilla Report 65833
   
   This occurs when the stacktrace message contains ]]>, which is the CDATA
   end code. There is no escape, so it must be replaced with `]]` + `]]>` +