jkesselm commented on PR #129:
URL: https://github.com/apache/xalan-java/pull/129#issuecomment-1829957912
Haven't looked at Spock, or the differences between junit 4 and 5, so I
don't have a valid opinion. What's current preference/recommendation in the
rest of Apache, or is there no consensus?
Apologies if I gave the impression that I was against starting to add tests.
I just didn't want to deal with the complication of restructuring out test
suite until we had a build which passed the existing tests and/or tests which
approved the new build. If you feel like dropping in a proposed framework, to
be filled in more completely later, go for it.
@vlsi, if you want to start looking at porting the test suite to a modern
framework, that's a big task (in many annoying bite-sized units) that would be
a significant contribution. We could probably migrate from our old
processor-plugin layer to TrAX, now that it's an accepted standard, though we'd
still want to have buckets which also regression test Xalan's own APIs.
Note: our test suite includes tests of W3C defined behaviors that we know we
didn't implement exactly as written. Currently our drivers run these but know
failures on them are not regressions when testing Xalan. We'd want to have the
same capability in the new version. Addressing that cleanly might be the major
design effort in this port.
--
/_ Joe Kesselman (he/him/his)
-/ _) My Alexa skill for New Music/New Sounds fans:
/ https://www.amazon.com/dp/B09WJ3H657/
Caveat: Opinionated old geezer with overcompensated writer's block. May be
redundant, verbose, prolix, sesquipedalian, didactic, officious, or redundant.
________________________________
From: Alexander Kriegisch ***@***.***>
Sent: Tuesday, November 28, 2023 1:52:45 AM
To: apache/xalan-java ***@***.***>
Cc: Joe Kesselman ***@***.***>; Mention ***@***.***>
Subject: Re: [apache/xalan-java] Make version classes work when Xalan is on
bootstrap classpath (PR #129)
@kriegaex commented on this pull request.
________________________________
In
serializer/src/main/java/org/apache/xml/serializer/Version.java<https://github.com/apache/xalan-java/pull/129#discussion_r1407301019>:
> + ClassLoader classLoader = Version.class.getClassLoader();
+ if (classLoader == null) {
+ // Oops! Someone put Xalan is on the bootstrap class loader (BCL) ->
fall
+ // back to the system class loader, because there is no Classloader
+ // instance for the BCL (native code). Due to class loader hierarchy,
+ // however, the resource will also be found when asking for it from a
+ // level below the BCL.
+ classLoader = ClassLoader.getSystemClassLoader();
+ }
+ try (InputStream fromResource =
classLoader.getResourceAsStream(POM_PROPERTIES_PATH)) {
First of all, @vlsi<https://github.com/vlsi>, I am glad to take suggestions
from you, but no orders. Earlier we talked about test automation several times,
and nowhere did anyone tell me to add test plugins or dependencies before the
Maven cutover. @jkesselm<https://github.com/jkesselm> added a JUnit 4
dependency for future use, but told me it was out of scope for the cutover. Now
you are sort of commanding me to do the opposite, i.e. use JUnit 5 (Jupiter)
instead of 4 and add tests instead of waiting for the cutover. Whom should I
follow now? Are you in any position to speak authoritatively and command me to
do such things? You are not even working actively on the Maven branch, because
in your opinion Maven is a (quote) "waste of time".
Theoretically assuming for a minute, I would add tests separately from
xalan-test, what would be the consequence? Tests would diverge, because they
would be maintained in two places. After the cutover, some of the xalan-test
tests might need adjustment anyway, if they make any assumptions about project
structure, dependencies etc. As soon as anyone would start merging them into
this project to make things easier in the future, that person would have to
reconcile my tests with the migrated ones. We might even have two different
test frameworks, JUnit 4/5 vs. the currently used home-brew framework of
xalan-test. I guess, in a first step when migrating them into this project, we
would need to run them from Surefire (unit tests) and Failsafe + Invoker
(integration tests) as-is, i.e. make sure to run them without first migrating
them to JUnit, if the latter would be a huge effort. My handful of new tests
might even be an impediment during that phase. I can easily add those test
plugins
and write a handful of tests, but it is not my decision to start adding big
new features to the Maven build, further stalling the cutover.
Besides, I did not add the version modules. They already existed without any
test coverage. I merely ported them to the Maven build and according to the
boyscout rule changed the way they work while retaining the API, because I
wanted to avoid code generation magic in favour of simple resource filtering.
So, thanks for your opinion. I know you want the right thing. I am not
arguing about that, we are on the same page there. I simply do not want to mix
this with the Maven cutover, so our disagreement is not about "new tests
yes/no" but about "new tests now/later".
@jkesselm<https://github.com/jkesselm>, I know we are talking post factum,
because the PR was already merged. Would you have me add test frameworks and
tests rather now or later? If now, then which testing tool and version are you
envisioning? My suggestion is Spock. A more conservative person would probably
suggest JUnit 5 Jupiter, an even more conservative one JUnit 4.
—
Reply to this email directly, view it on
GitHub<https://github.com/apache/xalan-java/pull/129#discussion_r1407301019>,
or
unsubscribe<https://github.com/notifications/unsubscribe-auth/A7OJ6WZQQCWR2G6OUXPHCBLYGWC33AVCNFSM6AAAAAA7Z4WVGSVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTONJSGE3TIMJQGI>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
