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]
