I've requested that my account be updated. Theoretically when that
happens folks should get notified and we can check and/or restore my
permissions.
I have the tests/jira directory working, with replacement tests for
tests/2.7.3_release. Currently that works like the tests/bugzilla
directory, able to support both simple
compare-transformation-against-expected tests and java-based tests for
things that require either more setup (eg changing timezone) or more
detailed examination of the output (checking the formatting of that output).
One of these bug-report tests appears to be recastable as an equivalent
of tests/conf-fail for exslt -- which would require adding an exslt-fail
directory and configuring another build target for it.
Ideally, I'd like to reconsider the test architecture, since java-based
tests may be appropriate in other categories; having type of test
hardcoded into the build by directory is a bit inelegant. Among other
things, as bugzilla/jira reports are resolved, it would be good to move
them out of those directories and into the appropriate directory for the
section of the system they're testing. An alternative would be to have
bugzilla-resolved and jira-resolved directories, which would avoid
disrupting the existing test framework, but which would mean looking
multiple places to find a test related to a given set of functionality.
Note that a number of the tests in the bugzilla directory are now
passing, which suggests that they *should* be moved/marked as resolved
(assuming that the issues they were responding to have indeed been
addressed, and that they aren't failing on a platform I haven't tested on.)
I have an eclipse .project file for the current arrangement of
xalan-java and xalan-test as peers. It includes necessary paths to
eliminate the classpath issues a naive load into Eclipse will report for
xalan-test. If we decide to refactor xalan-test into xalan-java, I'll
want to rework this but could then commit it to git so setup is easier
for other folks.
Re test output: The logging system does have a distinction between
ERROR, INFO, and STATUS messages. We've often been a bit sloppy about
distinguishing these, but we could review and make sure things are
categorized correctly, then have the smoketest builds run with only
ERROR and above enabled. That should cut down a lot of the chatter.
Similarly, there are a few thousand compiler warnings being issued, and
many of them can be trivially fixed -- for example, the type-mismatched
comparisons against Strings generally just want a .toString() inserted
on the non-String side. Others might take a bit more effort but should
be resolvable. Again, a cleaner build makes seeing actual issues much
easier.
And I believe we still have some open issues to be addressed.
I'd suggest resolving technical debt would be a worthwhile investments
in the codebase before starting significant new development. It isn't as
exciting, but it avoids trying to develop on top of a questionable base.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org
For additional commands, e-mail: dev-h...@xalan.apache.org
