To me, this all feels like we would have an easier time, if we prioritized porting the build to Maven.
(AFK, travel day) Gary On Tue, May 30, 2023, 07:27 Vladimir Sitnikov <sitnikov.vladi...@gmail.com> wrote: > > if any of the non XalanJ persons create any of the PRs that XalanJ > > committers might review. > > Do you think you have cycles to review > https://github.com/apache/xalan-java/pull/1 <-- This is a trivial change, > and impacts users > and > https://github.com/apache/xalan-java/pull/2 > ? > > >if any of the non XalanJ persons create any of the PRs that XalanJ > >committers might review. > > I am not comfortable creating PRs when there's no CI to capture bugs. > I expect that enabling tests in CI would attract contributors, and it > would allow capturing bugs earlier. > > >But right now, no one other than *myself* is trying to > >commit any dev code changes within XalanJ repos > > I see it might sound awkward to create PRs "for your own", > however, I believe creating PRs would invite others to review: > * PR gives a better understanding of what has changed > * they could see the code compiles and it passes tests > * they could comment on the lines of code > * PR can contain a work-in-progress state for early preview > > Have you considered inviting me as a committer? > > I'm not using Xalan extensively, however, I'm maintaining Apache JMeter, > and it relies on Xalan in public APIs. > > > But I'd wish, if someone may spend enough time to study the logic > > within the .xsl files that're provided with this test suite, and point > > out the defects, instead of *just/only* looking at method names, > > I can't speak for everybody, however, it is unsatisfying to review code > that uses obscure variables and method names. > It is hard to review code that takes bits from different places rather > than pass string literals. > > Have you considered using string literals for the input data? > Let us discuss a test: > https://github.com/apache/xalan-java/blob/986ec08c365a57853d09f7ffaa99238528e853ee/tests/org/apache/xalan/xpath3/FnTokenizeTests.java#L78-L82 > > input: test1_a.xml (2 lines) > xls: test1.xsl (38 lines) > output: test1.out (4 lines) > > In fact, the input XML is just <?xml ...?><elem>abracadabra</elem> > XLS contains two tests: > <xsl:template match="/elem"> > <elem> > <count><xsl:value-of select="count(.)"/></count> > <count><xsl:value-of select="count(tokenize(., > '(ab)|(a)'))"/></count> > </elem> > </xsl:template> > > Frankly speaking, I have no idea what count(.) is doing there. Is it > testing fn-tokenize somehow? > It does not look connected with the fn-tokenize. > So I believe it is not really needed for the test. > > It looks like the actual test behind FnTokenizeTests.test1 is as follows: > > given input "abracadabra", and template "count(tokenize(., '(ab)|(a)'))" > expect "6" as the output. > > That one line describes 2+38+4=40 lines of the test data in the repository. > > Now as the meaning of the test is reverse-engineered, let us try to make > it easier to understand for everybody: > > class FnTokenizeTest { > @Test > public void countTokenizeRegexp() { > assertValueOf(/* input = */ "abracadabra", /* xls = */ > "count(tokenize(., '(ab)|(a)'))", /* output = */ "6"); > } > } > > The assertValueOf method could create in-memory XMLs for input and XSL, > and it would likely be useful for many other tests as well. > Modern Java and Kotlin have even multiline string literals, so declaring > XMLs in place would make it much easier to create, and review tests. > > I hope that helps understand my suggestion. > > Vladimir > >
