Provide a lightweight Peppol BIS Europe Billing validation artifact

[gregjotau]

Use case

Applications that only validate Peppol BIS Europe Billing UBL invoices and credit notes currently need the full phive-rules-peppol aggregate.

For example, an embedded Peppol AP using PeppolValidation2025_11 only for VID_OPENPEPPOL_INVOICE_UBL_V3 and VID_OPENPEPPOL_CREDIT_NOTE_UBL_V3 still receives dependencies and resources for procurement documents, UBL 2.3, CII, TDD formats and all PINT regions.

With phive-rules-peppol:4.3.8, the published POM directly brings in:

• ph-ubl21
• ph-ubl23
• ph-cii-d16b
• phive-rules-en16931
• Oman, Slovakia, UAE and ViDA TDD datatype artifacts

The main jar also contains rule resources for multiple historical European releases and PINT A-NZ, EU, Japan, Malaysia, Oman, Singapore and UAE.

In one Spring Boot application this resolves to approximately:

• 4.5 MB for phive-rules-peppol
• 4.0 MB for ph-ubl23
• 2.3 MB for phive-rules-en16931
• 0.6 MB for ph-cii-d16b
• 0.2 MB for the TDD datatype artifacts

These are compressed jar sizes. The application needs ph-ubl21 and the two current European Billing validation sets, but none of the other document types or regions.

A consumer cannot simply exclude UBL 2.3 because the release-specific init methods register procurement validation sets that reference UBL23Marshaller.

Proposal

Would you consider publishing a smaller optional artifact, for example phive-rules-peppol-billing-eu, that contains only:

• current and upcoming Peppol BIS Europe Billing invoice and credit-note validation sets
• the applicable UBL 2.1 XSD and Schematron resources
• the minimum phive/rules dependencies needed for those validation sets

An alternative API shape would also help, such as billing-only initialization methods plus separately published resource artifacts, if that fits the project better.

The existing phive-rules-peppol aggregate could remain unchanged for compatibility. This would primarily help embedded APs, serverless validators, CLI tools and native/container deployments where classpath size and startup work matter.

phase4-peppol-client also depends on the aggregate, so a lightweight artifact could potentially benefit phase4 consumers if phase4 later offers an opt-in slim client dependency.

I searched the open and closed issues and discussions but did not find an existing modularization proposal. Please close this if the additional release/module maintenance would outweigh the benefit.