You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The existing fe-common module has accumulated heavy dependencies over time (Guava, Hadoop,
ANTLR, Alibaba MaxCompute SDK, etc.), making it unsuitable as a lightweight shared library for the
plugin/SPI ecosystem. When SPI plugin authors depend on fe-common, they are forced to pull in
dozens of transitive dependencies that have nothing to do with their plugin logic.
We need a zero-dependency foundation module that sits below fe-common and fe-extension-spi
in the dependency hierarchy, providing only the most essential, general-purpose utilities that any
module — including SPI plugins — can safely depend on.
2. Naming Decision
Candidate
Verdict
fe-foundation
Chosen. Clear "below-common" semantics. No ambiguity with existing modules.
fe-base
Too generic; widely used in other contexts.
fe-essentials
Good semantics but verbose.
fe-primitives
Implies primitive types; misleading.
fe-toolkit
"Toolkit" implies a heavier helper library rather than a minimal foundation layer.
Depend on @SerializedName (Gson) for persistence. Moving would require adding Gson or breaking persistence compatibility.
Writable, Codec, CountingDataOutputStream, DataInputBuffer, DataOutputBuffer, etc.
Deeply embedded in the persistence layer (194+ importers for Writable). High-risk migration better done in a separate phase.
CloudCredential
Depends on commons-lang3. Could be migrated after trivial refactoring.
GZIPUtils, EnvUtils
Depend on commons-io / Guava. Could be migrated after trivial refactoring.
8. Serialization Safety Analysis
All 10 classes are SAFE to move (package rename):
None implement java.io.Serializable (except StoragePropertiesException via Throwable,
but it is never serialized to disk)
None are registered in RuntimeTypeAdapterFactory (no class name stored in JSON)
None have serialVersionUID
All are either annotations, static utility classes, or transient runtime objects
No class name is stored in any editlog, metadata image, or checkpoint
9. Migration Strategy
Phase 1 (This PR): Backward-Compatible Migration
Create fe-foundation module with zero dependencies
Copy classes to new org.apache.doris.foundation.* packages
In original locations, replace class bodies with extends/delegation to the foundation class:
// fe-core: org.apache.doris.datasource.property.ParamRules// Now just re-exports the foundation classpackageorg.apache.doris.datasource.property;
publicclassParamRulesextendsorg.apache.doris.foundation.property.ParamRules {}
No existing code needs to change import statements
New code should prefer importing from org.apache.doris.foundation.*
Phase 2 (Future): Gradually update imports across the codebase
Update import statements in fe-core to use foundation packages directly
Deprecate and eventually remove the re-export shims
Migrate more classes from fe-common (IO utilities, Pair/Triple after decoupling Gson)
10. Build Configuration
<!-- fe-foundation/pom.xml -->
<artifactId>fe-foundation</artifactId>
<packaging>jar</packaging>
<name>Doris FE Foundation</name>
<description>Zero-dependency foundation utilities for Doris FE modules and SPI plugins</description>
<dependencies>
<!-- Intentionally empty. This module has ZERO third-party dependencies. -->
</dependencies>