[jira] [Comment Edited] (XERCESJ-1795) Migrate Xerces-J Build System to Apache Maven

    [ https://issues.apache.org/jira/browse/XERCESJ-1795?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D18=
074215#comment-18074215 ]=20

Elliotte Rusty Harold edited comment on XERCESJ-1795 at 5/28/26 10:44 PM:
--------------------------------------------------------------------------

Any "modern automated security auditing" that can't handle Xerces is bad an=
d should feel bad. We don't need to and shouldn't change our build system t=
o support busted, poorly designed security tools that aren't very useful an=
d wrong more often than they're right.

Switching JDKs is a completely separate issue. Again, let's try not to mix =
up orthogonal points.

JPMS also does not necessitate Maven. If there are improvements that need t=
o be made there, file a separate issue. (Not that JPMS is useful or that an=
yone should be using it for anything, but it does show up so we should at l=
east try not to make developers' work harder.)

I'm not familiar with the PsychoPathXPath issues you cite, but again that h=
as nothing to do with moving to Maven. Please file an issue with details on=
 that.

A familiar lifecycle is a benefit of Maven, and might be worth doing, thoug=
h there's likely not sufficient developer availability right now to priorit=
ize this. Other improvements need not wait for this to happen.=20





was (Author: elharo):
Any "modern automated security auditing" that can't handle Xerces is bad an=
d should feel bad. We don't need to and shouldn't change our build system t=
o support busted and badly designed security tools that aren't very useful =
and wrong more often than they're right.

Switching JDKs is a completely separate issue. Again, let's try not to mix =
up orthogonal points.

JPMS also does not necessitate Maven. If there are improvements that need t=
o be made there, file a separate issue. (Not that JPMS is useful or that an=
yone should be using it for anything, but it does show up so we should at l=
east try not to make developers' work harder.)

I'm not familiar with the PsychoPathXPath issues you cite, but again that h=
as nothing to do with moving to Maven. Please file an issue with details on=
 that.

A familiar Lifecycle is a benefit of Maven, and might be worth doing, thoug=
h there's likely not sufficient developer availability right now to priorit=
ize this. Other improvements need not wait for this to happen.=20




> Migrate Xerces-J Build System to Apache Maven
> ---------------------------------------------
>
>                 Key: XERCESJ-1795
>                 URL: https://issues.apache.org/jira/browse/XERCESJ-1795
>             Project: Xerces2-J
>          Issue Type: Improvement
>            Reporter: Svante Schubert
>            Priority: Major
>
> *strong text*h3. Description
> Following project discussions regarding build reproducibility and transpa=
rency, I propose a formal migration of the *Xerces-J* build system from *An=
t* to {*}Apache Maven{*}. While the current Ant-based system is functional,=
 it relies on manual environment management and opaque binary dependencies =
that complicate modern automated security auditing and contributor onboardi=
ng.
> h3. Rationale for Migration
> Transitioning to Maven will align Xerces-J with standard Apache ecosystem=
 practices and provide several key benefits:
>  * *Transparency & Security:* Ensures all dependent sources are publicly =
available and verifiable, mitigating risks associated with supply chain att=
acks from opaque JAR binaries.
>  * *Standardised Lifecycle:* A uniform build structure (e.g., {{{}src/mai=
n/java{}}}) makes it easier for new contributors to engage with the project=
 without learning custom Ant scripts.
>  * *Modern Java Support:* Facilitates the addition of *Java Module Inform=
ation* (JPMS), which is increasingly required by modern applications using =
Xerces-J.
>  * *Dependency Management:* Enables automatic vulnerability scanning and =
resolves long-standing conflicts (e.g., IntelliJ flagging API overlaps betw=
een {{XercesImpl}} and the JDK).
> h3. Technical Considerations & Known Hurdles
> A prototype has already identified specific challenges that this issue mu=
st address:
>  * *Target JDK:* The proposed baseline is {*}JDK 11{*}, the first LTS rel=
ease supporting the JDK module refactoring. Allowing us to enable the Java =
Platform Module System.
>  * *Hybrid Solution:* For "special build features" that do not map cleanl=
y to Maven=E2=80=99s declarative model, specific Ant scripts may be retaine=
d as a documented hybrid solution within the new structure.
>  * *Project Structure:* Maven requires a more explicit division of code i=
nto defined subfolders. Two years ago, the Xerces sources were on a differe=
nt branch than their tests, making regression testing difficult.
>  * *Dependency Issues (PsychoPathXPath Processor):* Two years ago, the XP=
ath 2.0 engine had historically caused security exceptions and suffered fro=
m inconsistent source availability at Eclipse. A specific version with "fin=
dable" sources must be used to remain compliant with Apache guidelines.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)