I have basically understood the proposal.

Should we first attempt to submit a PR so as to have a better
discussion with other community members?

Best Regards,
Delei

On Wed, Jan 7, 2026 at 6:04 PM Shuxin Pan <[email protected]> wrote:
>
> Hi Community and Mentors,
>
> We are currently preparing for Apache Fesod (incubating) 0.1.0-RC2.
>
> I would like to initiate a discussion regarding the handling of
> CGLIB/ASM dependencies to address the valid concerns raised regarding
> the fastexcel-support module during the RC1 vote.
>
> 1. The Issue in RC1 , we included a standalone fastexcel-support
> module containing repackaged ASM and CGLIB classes. Our mentor
> rightfully pointed out [1]:
>
> "What is fastexcel-support-1.3.0.jar? ... Are these copies of the
> classes from the asm and cglib projects? If so, the licenses/LICENSE
> file appears invalid."
>
> 2. Clarification of Origin To clarify: These classes were NOT copied
> from the original ASM (BSD) or CGLIB (ALv2) projects. They were shaded
> (extracted and relocated) from spring-core (which is Apache License
> 2.0).
>
> Why shading? The upstream CGLIB project is unmaintained. The fork
> maintained within the Spring Framework has become the de facto
> standard, supporting newer JDKs (e.g., Java 17/21).
>
> The Oversight in RC1: While the license (ALv2) is compatible, we
> failed to include the required Attribution for the Spring Framework in
> the NOTICE file. This made the origin of the classes unclear and the
> License file appear incomplete.
>
> 3. Proposed Solution for RC2 To resolve this ambiguity and strictly
> follow the "Source Release is King" principle, we propose the
> following changes:
>
> A. Remove the fastexcel-support module: We will delete this standalone
> module entirely to avoid confusion in the source package.
>
> B. Implement "Internal Shading": We will move the shading logic
> directly into the build cycle of the main module (where these classes
> are actually used) using the maven-shade-plugin. This will:
>
> - Extract necessary classes from spring-core.
>
> - Relocate them to org.apache.fesod.shaded.* to prevent transitive
> dependency conflicts (Dependency Hell).
>
> - Exclude spring-core from the generated POM (dependency-reduced-pom).
>
> C. Strict Attribution Compliance: We will update the META-INF/NOTICE
> file to explicitly acknowledge the Spring Framework, fulfilling our
> obligations under the Apache License 2.0.
>
> 4. Alignment with ASF Practices This "Internal Shading + Relocation"
> pattern is a standard best practice used by projects like Apache Flink
> to safely vendor critical dependencies.
>
> We believe this plan resolves the licensing ambiguity and ensures a
> clean, compliant source release.
>
> If there are no objections, we will proceed with this strategy for RC2.
>
> [1] https://lists.apache.org/thread/vw70x0pm9zd1odgn2mp9nlcg58mfod6x
>
> Best,
> Shuxin Pan
> Apache Fesod PPMC member
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to