Hi Svante,
I agree with you on following points, with few of my own suggestions as
well.
1) Including Xerces XML Schema 1.1 test suite files with XML Schema 1.1
implementation sources. This should be straight forward I think, as a
folder include.
2) Having Xerces Maven build as preferred over an Ant build. I think, that
it may be ok to have new Xerces Maven branches and also retaining Ant
branches for archival interest.
Regards,
Mukul
Mail sent from android device, please excuse any typos
On Sun, 19 Jan, 2025, 21:14 Svante Schubert, <[email protected]>
wrote:
> Dear Elliotte, Dear Mukul,
>
> On Sun, 12 Jan 2025 at 13:27, Elliotte Rusty Harold <[email protected]>
> wrote:
>
>> On Sun, Jan 12, 2025 at 7:58 AM Mukul Gandhi <[email protected]>
>> wrote:
>> >
>> >
>> > This is true, while having GitHub as repos source. But for the next
>> Xerces-J release I've a feeling that we can make a release without
>> implementing this. A question definitely comes that, whether we should
>> delay the next release for probably long time to implement and test this
>> feature, or having a next release fairly quickly without having automated
>> regression tests.
>>
>> The latter. In general I like to push out small changes before
>> commencing work on big projects. It's like letting the person with one
>> gallon of milk go in front of your stuffed shopping cart in the
>> supermarket checkout line.
>>
>> Also, while working on github, make sure it's still possible to
>> release from the old system if required for emergency security fixes.
>>
>>
>>
> Striving for automation as quickly as possible usually saves you time and
> will give you more confidence in deliverables avoiding manual errors, and
> making processes reproducible.
> However, it would be sufficient if it is possible to reproduce as an
> external developer that all tests run without errors and that the sources
> for all dependencies are available.
> Correct me if I am wrong, but that is a basic criterion of projects of the
> Apache Foundation, right?
>
> In addition, when I talked about adding the tests, I did not mean to add
> the XSD Test Suite, which I suggest referencing or implementing as a GitHub
> subrepository.
> I was referring to the xml-schema-1-1-tests branch, which should be merged
> with the xml-schema-1-1-dev branch.
> Perhaps I oversee the reason for the tests and sources in different
> branches, but I find it hard to use the tests of one branch to test the
> sources of another.
>
> If you fix an issue on a branch, what are the dependencies? How many
> branches do you have to touch?
> Are you able to reapply the fix by a simple "git rebase", like a feature
> branch - like an XSD 1.1 branch over an XSD 1.0 branch (aka trunk)?
> I suggest taking a look at the Xerces repository using GitKraken (or some
> similar branch viewing tool) to see the dependencies.
>
> Another challenge in transparency is the versioning of the dependencies
> listed as JARs in <xerces-j>/tools
> If I am not mistaken, the sources of PsychoPath XPath are nonexistent and
> are being flagged as problematic in terms of security.
>
> Apache Maven has over Apache Ant the advantage of having transparency over
> the used versions - the versions are being downloaded as binary and source
> and can be debugged and fixed.
> With Maven it is easy to switch versions for testing and make this switch
> transparent and trustworthy!
> Most of all, any developer can download the sources from GitHub and build
> & debug Xerces out-of-the-box, which is not so easy these days...
> When I aimed to switch from ANT to Maven and experimented with different
> JDK versions PychoPath turned out to be the biggest problem.
> Therefore, I invite you to stand on my shoulders and take a look at the
> branches of
> https://github.com/svanteschubert/xerces-j/branches
> with a tool such as GitKraken to understand the branches.
> I have written some months ago several emails to Xerces' user & dev list
> explaining the problems I have accounted for, guess there is no need to
> duplicate these emails.
>
> To sum it up: The issues I am mentioning might annoy you, as they have
> existed for a long time and no committer likes to touch them, but I think
> we all want the same thing in the end:
>
> 1. *Stability* - as not a single test is failing before a new release
> 2. *Transparency* - as all tests can be run (by any developer easily)
> and all sources of dependencies do exist!
>
> Thank you in advance,
> Svante
>
>
>
