Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Development Resources/HOWTO/Starting A New Project/Subproject or Component"

(Created page with "Before you start a new project at the Eclipse Foundation, it's a good idea to spend some time to see if the functionality that you'd like to provide can be included with an ex...")
 
(One intermediate revision by the same user not shown)
Line 20: Line 20:
 
# Does not reasonably fall within the scope of an existing project (and an existing scope cannot be reasonably changed to accommodate);
 
# Does not reasonably fall within the scope of an existing project (and an existing scope cannot be reasonably changed to accommodate);
 
# Absolutely must be delivered on a separate schedule;
 
# Absolutely must be delivered on a separate schedule;
# Must be delivered independently (i.e. a completely separate downloads area is required)
+
# Must be delivered independently (i.e. a completely separate downloads area is required);
 
# Has different licensing requirements; and/or
 
# Has different licensing requirements; and/or
 
# Would benefit from separate branding.
 
# Would benefit from separate branding.
  
 
If you're not sure, consider starting as a component of an existing project. If it becomes clear over time that a separate project is really required, then we can split the project via a restructuring review.
 
If you're not sure, consider starting as a component of an existing project. If it becomes clear over time that a separate project is really required, then we can split the project via a restructuring review.
 +
 +
If you do decide to create a new project, please see [[Development Resources/HOWTO/Starting A New Project|Starting a New Project]].

Revision as of 09:09, 16 March 2015

Before you start a new project at the Eclipse Foundation, it's a good idea to spend some time to see if the functionality that you'd like to provide can be included with an existing project.

If the new functionality falls within the scope of an existing project, then it can reasonably be a component within the project. Components are an informal concept for Eclipse projects; the notion of a component generally manifests as a separate Git repository with access to that repository managed via social convention. All project committers have uniform write access to all project resources. This means that when a new component is added to a project everybody who already has push access to the Git repositories already in that project can also push to the new component's Git repository.

If the fact that other people have access to your code scares you, then you may have some control issues to address. This is, after all, open source and the whole point is to grow diversity and encourage other people to join and contribute to your efforts. A lot of our open source projects already do this; the C/C++ Development Tools project, for example, has a number of separate functional areas (de facto components) and has successfully managed access via social convention for more than a decade.

Different components within a project can be built separately, but they generally release on a shared schedule with shared release reviews (although there is some precedent for projects releasing different components separately).

A component may be the right choice if the added functionality:

  1. Is within the scope of the project;
  2. Shares the same licensing of the project;
  3. Can reasonably share the development schedule of the project; and/or
  4. Will be delivered alongside other project functionality.

Note that project scope can be changed.

You might instead choose to create a new project if the added functionality:

  1. Does not reasonably fall within the scope of an existing project (and an existing scope cannot be reasonably changed to accommodate);
  2. Absolutely must be delivered on a separate schedule;
  3. Must be delivered independently (i.e. a completely separate downloads area is required);
  4. Has different licensing requirements; and/or
  5. Would benefit from separate branding.

If you're not sure, consider starting as a component of an existing project. If it becomes clear over time that a separate project is really required, then we can split the project via a restructuring review.

If you do decide to create a new project, please see Starting a New Project.

Back to the top