You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by Mukul Gandhi <ga...@gmail.com> on 2025/01/04 11:27:45 UTC
xml-commons source code copied to git
Hi all,
I've copied the xml-commons source code from Apache Xerces svn to
GitHub to following of the locations :
https://github.com/apache/xerces-j/tree/xml-commons-external,
https://github.com/apache/xerces-j/tree/xml-commons-resolver and have
updated the Apache XML Commons web site documentation page at
https://xerces.apache.org/xml-commons/.
I think that, this provides us with an integrated view of all Apache
Xerces-J source code on Xerces-J's repos at location
https://github.com/apache/xerces-j within all the respective branches
at this url.
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: xml-commons source code copied to git
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
No need for a separate ant branch. That's what git history is for.
I was looking at this today and moving to Maven will be a bit of slog.
A lot of this code is very strange by 2025 standards. There's a lot of
work to do first. In particular, not all the tests are based on JUnit.
They're manually executed through main methods. That's not going to
integrate well with what Maven expects. It's probably easier to fix
that first and then move it to Maven than the other way around.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: xml-commons source code copied to git
Posted by Mukul Gandhi <ga...@gmail.com>.
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, <sv...@apache.org>
wrote:
> Dear Elliotte, Dear Mukul,
>
> On Sun, 12 Jan 2025 at 13:27, Elliotte Rusty Harold <el...@ibiblio.org>
> wrote:
>
>> On Sun, Jan 12, 2025 at 7:58 AM Mukul Gandhi <ga...@gmail.com>
>> 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
>
>
>
Re: xml-commons source code copied to git
Posted by Svante Schubert <sv...@apache.org>.
Dear Elliotte, Dear Mukul,
On Sun, 12 Jan 2025 at 13:27, Elliotte Rusty Harold <el...@ibiblio.org>
wrote:
> On Sun, Jan 12, 2025 at 7:58 AM Mukul Gandhi <ga...@gmail.com>
> 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
Re: xml-commons source code copied to git
Posted by Elliotte Rusty Harold <el...@ibiblio.org>.
On Sun, Jan 12, 2025 at 7:58 AM Mukul Gandhi <ga...@gmail.com> 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.
--
Elliotte Rusty Harold
elharo@ibiblio.org
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: xml-commons source code copied to git
Posted by Mukul Gandhi <ga...@gmail.com>.
Hi Svante,
On Wed, 8 Jan, 2025, 15:04 Svante Schubert, <sv...@gmail.com>
wrote:
A new Xerces-J release is indeed great news!
>
To have Xerces-J's 2.12.3 release, someone needs to prepare RC from
Xerces-J's sources from GitHub repos and have RC reviewed by subscribers of
this list. I'm curious, whether other than me anyone else with Xerces
repos's commit privileges might like to prepare Xerces-J's RC for next
release?
> We both desire the same for Xerces to always be high-quality, stable and
> without regressions.
>
Definitely.
The common practice to achieve this is automated regression tests - like
> using GitHub functionality of automated builds and tests in the GitHub
> cloud for every commit/PR.
>
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.
To achieve this we must bring the tests and sources on the same branch.
>
With Xerces-J, the combined data size of Xerces-J's test sources and
supporting files is very big, due to which IMHO I think this may not be a
good approach. Also, doing this way shall require significant refactoring
with how Xerces-J's test suite is structured, and I don't think large
amounts of effort to do this is ok for the next release.
--
Regards,
Mukul Gandhi
Re: xml-commons source code copied to git
Posted by Svante Schubert <sv...@gmail.com>.
Hi Mukul,
A new Xerces-J release is indeed great news!
We both desire the same for Xerces to always be high-quality, stable and
without regressions.
The common practice to achieve this is automated regression tests - like
using GitHub functionality of automated builds and tests in the GitHub
cloud for every commit/PR.
To achieve this we must bring the tests and sources on the same branch.
Would you agree with the above so far?
In case you lack any kind of information or something is/was not well
explained by myself - please let me know!
What are your thoughts, your view of the pros/cons of this suggestion?
Kind regards,
Svante
On Sat, 4 Jan 2025 at 16:48, Mukul Gandhi <ga...@gmail.com> wrote:
> Hi Svante,
> I've been thinking of proposing making a new Xerces-J release.
> There are various new code changes on Xerces-J's repos, that I think
> are important enough for having a new Xerces-J release.
>
> Xalan-J's XSL 3 latest code also requires the new Xerces-J release.
>
> I'm really not sure how to go about adding the GitHub regression test
> that you've mentioned within your mail below.
>
> On Sat, Jan 4, 2025 at 5:25 PM Svante Schubert
> <sv...@gmail.com> wrote:
> >
> > Hello Mukul,
> >
> > Thanks for your contribution.
> >
> > What is your plan to bring all these branches together?
> > In general, we should avoid duplicated data, right?
> >
> > Kind regards,
> > Svante
> >
> > PS: I asked about the Xerces tests some months ago. We should add a
> GitHub regression test that always runs after every commit and stays green
> - I could not reproduce green tests for the last release.
>
>
> --
> Regards,
> Mukul Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>
Re: xml-commons source code copied to git
Posted by Mukul Gandhi <ga...@gmail.com>.
Hi Svante,
I've been thinking of proposing making a new Xerces-J release.
There are various new code changes on Xerces-J's repos, that I think
are important enough for having a new Xerces-J release.
Xalan-J's XSL 3 latest code also requires the new Xerces-J release.
I'm really not sure how to go about adding the GitHub regression test
that you've mentioned within your mail below.
On Sat, Jan 4, 2025 at 5:25 PM Svante Schubert
<sv...@gmail.com> wrote:
>
> Hello Mukul,
>
> Thanks for your contribution.
>
> What is your plan to bring all these branches together?
> In general, we should avoid duplicated data, right?
>
> Kind regards,
> Svante
>
> PS: I asked about the Xerces tests some months ago. We should add a GitHub regression test that always runs after every commit and stays green - I could not reproduce green tests for the last release.
--
Regards,
Mukul Gandhi
---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org
Re: xml-commons source code copied to git
Posted by Svante Schubert <sv...@gmail.com>.
Hello Mukul,
Thanks for your contribution.
What is your plan to bring all these branches together?
In general, we should avoid duplicated data, right?
Kind regards,
Svante
PS: I asked about the Xerces tests some months ago. We should add a GitHub
regression test that always runs after every commit and stays green - I
could not reproduce green tests for the last release.
On Sat, 4 Jan 2025 at 12:28, Mukul Gandhi <ga...@gmail.com> wrote:
> Hi all,
> I've copied the xml-commons source code from Apache Xerces svn to
> GitHub to following of the locations :
> https://github.com/apache/xerces-j/tree/xml-commons-external,
> https://github.com/apache/xerces-j/tree/xml-commons-resolver and have
> updated the Apache XML Commons web site documentation page at
> https://xerces.apache.org/xml-commons/.
>
> I think that, this provides us with an integrated view of all Apache
> Xerces-J source code on Xerces-J's repos at location
> https://github.com/apache/xerces-j within all the respective branches
> at this url.
>
>
> --
> Regards,
> Mukul Gandhi
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: j-dev-help@xerces.apache.org
>
>