DR-002-Strat: Eclipse Project Structure for S-Core#

  • Date: 2026-05-22

Eclipse Project Structure for S-Core
status: accepted
context: Strategy
decision: Option 1
dec_rec__strat__eclipse_project_structure
Decision Record

Context / Problem#

S-Core needs to decide how its modules are structured within the Eclipse Foundation and GitHub. Two organisational models are under consideration: keeping all modules within one Eclipse project (the current approach), or splitting each module into a separate Eclipse project.

The choice has implications for community governance, Committer nomination processes, GitHub organisation management, and the long-term risk to the S-Core v1.0 release.

Options Considered#

Option 1: One Eclipse Project (currently used)#

Supports the idea: “S-Core is a platform” (e.g. same as Android)

All S-Core relevant modules reside together in one GitHub organisation under one Eclipse project.

Fig. 28 Option 1 – One Eclipse project containing all S-Core repositories#

Pros

  • All S-Core relevant modules are together in one GitHub organisation → it is immediately visible what belongs to the S-Core project.

  • One infrastructure, one timeline, one community → things are kept together.

  • One authority (PLs) for all modules that can ensure the same behaviour for all modules.

Cons

  • Eclipse Foundation project handbook rules were not designed for such big projects. This leads among others to the following problems:

    • It is typically not possible to nominate initial Committers for newly contributed modules.

    • The Committer model does not completely scale for such big projects. Having a large number of modules in one Eclipse project leads to the necessity of having a big number of Committers with various areas of responsibility.

  • Community management and building is more complicated due to the size of the project.

Possible mitigation

  • Eclipse Foundation and PMC must acknowledge and agree that new modules in S-Core are treated as new Eclipse projects for the purpose of initial Committer nomination.

  • Mapping/restricting of Committer responsibilities in the project to dedicated areas is done using the CODEOWNERS file in GitHub (already in place).

Option 2: Multiple Eclipse Projects#

Supports the idea: “S-Core is a pure integration project” (e.g. same as Yocto)

Every module becomes its own Eclipse project; a central S-Core project serves as the integration project.

Fig. 29 Option 2 – Multiple Eclipse projects, S-Core as the central integration project#

Pros

  • Every module is a “small” Eclipse project, which is exactly what the Eclipse Foundation project handbook is built for → Clear Committer/Contributor/PL management.

Cons

  • Every project is a completely standalone project. The S-Core project PLs do not have tools to manage the separate Eclipse projects with implementation modules, which creates a significant risk that the S-Core community could fracture.

  • Every module/project has its own GitHub Organisation → enforcing the same rules and processes is complicated; belonging to S-Core project is not obvious.

Possible mitigation

  • S-Core becomes a “parent project” and all other S-Core relevant modules become sub-projects. This would make it clear that the modules are part of the S-Core project and it would still be easily possible to follow Eclipse project handbook rules for every sub-project, e.g. for initial Committer nomination.

  • The Eclipse Foundation technically enables S-Core and all sub-projects/modules to be located within the same GitHub organisation.

Conclusion#

We proceed with Option 1 and initiate a Proof of Concept for Option 2.

Rationale#

  • There are currently no major blockers that would make the switch to Option 2 obligatory.

  • Switching the structure of the project and module repositories poses a high risk for the S-Core v1.0 release, which is planned for the end of the year.

Follow-up Actions#

  • X-Core approaches Eclipse Foundation: Eclipse Foundation and PMC must acknowledge and agree that new modules in S-Core are treated as new Eclipse projects for the purpose of initial Committer nomination.

  • POC for Option 2: The OpenSOVD project and its integration into S-Core will be used as a Proof of Concept (POC) for Option 2.

  • The topic should be revisited after the S-Core v1.0 release is delivered.