I wouldn't be against keeping the fastexcel-support dependency for this release. We can revisit it later.
On Wed, 7 Jan 2026 at 13:34, PJ Fanning <[email protected]> wrote: > > It is not required to abandon the dependency on fastexcel-support. It > would be nice to not have it as an external jar and preferable to have > it maintained inside the Apache Fesod podling. > If we keep it as an external jar, it would be preferred if that jar > had an improved META-INF LICENSE and NOTICE. > If we bring it inside the Fesod tent then it must have an improved > META-INF LICENSE and NOTICE. > > In summary, we can keep using fastexcel-support as an external jar but > it seems untidy to have what is essentially a Fesod jar but maintained > outside of the ASF so that you can avoid applying the correct > licensing to it. > > On Wed, 7 Jan 2026 at 11:48, Shuxin Pan <[email protected]> wrote: > > > > Hi PJ Fanning, > > > > Thank you for the feedback. Here are the clarifications and our action > > plan regarding your questions, plus one follow-up inquiry regarding > > the project structure. > > > > 1. Regarding Spring's maintenance of CGLIB: Yes, the Spring team > > maintains an active internal fork of the code, rather than just > > repackaging binaries. > > > > The original upstream CGLIB project is unmaintained and lacks support > > for modern Java versions. The Spring team has applied significant > > patches to their internal version to ensure compatibility with newer > > JDKs (e.g., JDK 17/21). This maintained codebase is essential for > > Fesod. > > > > 2. Regarding LICENSE and NOTICE files requirements: Understood. We > > missed the requirement to explicitly document bundled ALv2 artifacts > > in the LICENSE file. For RC2, we will strictly follow the bundling > > rules: > > > > META-INF/LICENSE: We will append a section to the LICENSE file > > explicitly stating that the artifact bundles code from the Spring > > Framework (APLv2). > > > > META-INF/NOTICE: We will propagate the relevant attribution notices > > from spring-core's NOTICE file into our project's NOTICE file. > > > > 3. Follow-up Question regarding Project Structure: If we strictly > > implement the LICENSE and NOTICE fixes mentioned above, is it > > acceptable to continue using the separate fastexcel-support jar > > (module)? > > > > We prefer to keep fastexcel-support as a standalone dependency that > > handles the shading, rather than moving the shading logic directly > > into the fesod source tree (Internal Shading). Our question is: As > > long as the licensing compliance is strictly resolved, is it > > permissible to maintain this separate module structure for the > > release? > > > > Best , > > Shuxin Pan > > > > On Wed, Jan 7, 2026 at 6:10 PM PJ Fanning <[email protected]> wrote: > > > > > > * Have Spring team forked the cglib code or are they just packaging > > > the unmaintained cglib classes (with shaded package names)? > > > * If we include 3rd party classes in our jars, we will need to add > > > details in the META-INF/LICENSE file that we include in the jar - even > > > if they are Apache licensed. Possibly also, META-INF/NOTICE depending > > > on if the 3rd party classes have NOTICE files that we need to > > > acknowledge. > > > > > > On Wed, 7 Jan 2026 at 11:03, 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] > > > > > > > --------------------------------------------------------------------- > > 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]
