Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
CBI/Distribution
This page tracks information related to how code, configuration, build artifacts, bundles, packages, and more are distributed at Eclipse.
Contents
Background
Eclipse projects consume 3 types of software:
- Approved unmodified third party software
- Approved modified third party software - with contentious bits removed to make it acceptable to Eclipse's IP policy
- Eclipse software from other projects (or itself in the case of large projects with multiple parts)
Overview
The following is an image depicting repositories of software at Eclipse, processes that consume and produce output, and the flows between processes.
Guide
Build process
1 - Hudson executes the build (or local developer initiates manually)
2 - Code and config is cloned from git
3 - Libraries are downloaded from either a) Orbit as a zip file b) maven.eclipse.org as maven repositories c) downloads.eclipse.org as p2 repositories
4 - The build executes, outputs p2 repositories
5 - Packaging takes place, outputs packages
Notes
CQ - 3rd party libraries are reviewed and approved/rejected. Approved libraries are stored in Orbit
ECO - Eclipse technology is consumed by the ecosystem at large
Red arrows denote a path that would be useful, but may not exist today
Dashed arrows are strictly a manual process
Areas of concern
Eclipse technology redistribution
Orbit provides a centralized clearing house for IP policy approved 3rd party dependencies. At the moment, projects consuming technology from other Eclipse projects do so in a variety of ways. People picking up this technology are left to discover the chain of transitive dependencies.
This is an issue for Eclipse projects, and also for technology outside of Eclipse that uses Eclipse components.
Move to other forges
The LTS and Polarsys programs must ensure that all dependencies are available from an Eclipse Foundation controlled source. This includes all 3 types of software as listed above. As well, the LTS forge is for members only. Binaries for software involved with LTS must only be available to members both for consumption and once it is produced.
Thus, for a given developer from a specific company working on LTS software, their preference will be this order:
- Developer or company specific software in the LTS forge
- Generic re-usable components from the LTS forge
- Generic re-usable components from the Community forge