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 "CBI"

(Meeting Minutes)
(Hudson / Jenkins)
(39 intermediate revisions by 9 users not shown)
Line 1: Line 1:
 
The Eclipse Common Build Infrastructure (CBI) is an initiative combining technologies and practices for building Eclipse Software.
 
The Eclipse Common Build Infrastructure (CBI) is an initiative combining technologies and practices for building Eclipse Software.
  
==Initiative Goals==
+
==What is CBI==
  
===Primary===
+
The core of CBI today is Maven with the Tycho plugins. The Tycho plugins teach Maven how to build (and consume) Eclipse plugins and OSGi bundles. This enables building Eclipse projects with "maven clean install" just as one would build other Maven projects.
 +
 
 +
Common services such as the Jar signing facility, MacOS signing facility, and Windows signing facility are also included with CBI. Other tools and services may be included in the future as the need arises.
 +
 
 +
Over time mature templates and common pom.xml files will be provided that set common values finely honed with experience.
 +
 
 +
One might go so far as to include Git, Hudson/Jenkins, the build slaves, and Nexus (aka. the artifact repository & server side of Maven) as part of CBI since they are also common and crucial to builds.
 +
 
 +
Gerrit, Bugzilla, and the Downloads site are closely related. Some might consider them part of CBI as well.
 +
 
 +
==Initiative Goals==
 +
Primary goals are:
 
* Make it really easy to contribute Eclipse projects
 
* Make it really easy to contribute Eclipse projects
 
** Make it really easy to copy & modify source
 
** Make it really easy to copy & modify source
Line 11: Line 22:
 
** Make it really easy to sign software
 
** Make it really easy to sign software
  
===Secondary===
+
Secondary goals are:
 
* Get all Eclipse projects building their software on Eclipse Foundation hardware.
 
* Get all Eclipse projects building their software on Eclipse Foundation hardware.
 
* Enable the [http://wiki.eclipse.org/EclipseLTS Long Term Support Program].
 
* Enable the [http://wiki.eclipse.org/EclipseLTS Long Term Support Program].
 
+
* Make it easy for people to build custom Eclipse distributions.
  
 
There is a strong link between CBI and the [http://wiki.eclipse.org/EclipseLTS Long Term Support Program] which enables a marketplace of companies providing maintenance and support for Eclipse technologies for durations far beyond typical community support. Please NOTE: CBI features will be available to community.
 
There is a strong link between CBI and the [http://wiki.eclipse.org/EclipseLTS Long Term Support Program] which enables a marketplace of companies providing maintenance and support for Eclipse technologies for durations far beyond typical community support. Please NOTE: CBI features will be available to community.
Line 20: Line 31:
 
It is our hope that this project develops an offering that is compelling so that many projects will move to use it.
 
It is our hope that this project develops an offering that is compelling so that many projects will move to use it.
  
==Next meeting==
+
==Who is using it?==
  
* Bi-weekly conference call, Tuesdays 10:00 to 11:00 Eastern timezone. [http://wiki.eclipse.org/CBI/Conference Conference bridge details]. Contact andrew dot ross at eclipse dot org if you would like to be added to the Calendar reminder.
+
There's a [http://wiki.eclipse.org/CBI/Projects list of projects] building with CBI available.  
* Code Sprint #2 - in July, 2012
+
The Eclipse Foundation would like to have more than 50% of projects building with CBI by end of 2013.
  
==GSoC==
+
[http://wiki.eclipse.org/Platform-releng/Platform_Build Eclipse Platform Build is based on CBI] see the [[CBI/Eclipse Platform Build Roadmap]]
 
+
There are opportunities for students interested in participating in Google Summer of Code. Please see our list of [http://wiki.eclipse.org/Google_Summer_of_Code_2012_Ideas project ideas and scan for CBI].
+
 
+
==Resources==
+
* mailing list [https://dev.eclipse.org/mailman/listinfo/cbi-dev cbi-dev]
+
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap&product=CBI&list_id=38248 List of Bugs] (Product = CBI)
+
 
+
==Notable Implementations==
+
* [[CBI/Eclipse Platform Build]] see the [[CBI/Eclipse Platform Build Roadmap]]
+
* [http://www.fosslc.org/drupal/content/tycho-good-bad-and-ugly Video discussing JBoss tools use of Tycho]
+
  
 
==Preferred Build Technologies==
 
==Preferred Build Technologies==
  
===Hudson===
+
===Hudson/Jenkins===
  
* The Eclipse [http://hudson.eclipse.org Hudson instance]; and
+
* [http://ci.eclipse.org The list of Hudson/Jenkins instances at Eclipse]
* Hudson projects using [https://hudson.eclipse.org/hudson/view/Tycho%20+%20Maven/ Maven and Tycho].
+
* [[Hudson | Hudson/HIPP docs]]
 +
* [[Jenkins]]
  
 
===Maven===
 
===Maven===
Line 62: Line 64:
 
* [[Tycho/Reference_Card|Reference Card]]
 
* [[Tycho/Reference_Card|Reference Card]]
 
* [[Tycho/Packaging_Types|Packaging Types]]
 
* [[Tycho/Packaging_Types|Packaging Types]]
 +
 +
=== p2 Repo checks ===
 +
 +
It's highly recommended that any Eclipse.org project runs frequently, and maybe even systematically, the [[CBI/p2repoAnalyzers/Repo Reports|p2 repo analyzer]] to make sure it conforms to some requirements of being a nice citizen in the Eclipse.org world.
 +
 +
===Nexus===
 +
 +
[[Services/Nexus]]
  
 
===Signing tool===
 
===Signing tool===
  
[http://wiki.eclipse.org/IT_Infrastructure_Doc#Sign_my_plugins.2FZIP_files.3F On demand signing tool]
+
* [http://git.eclipse.org/c/cbi/org.eclipse.cbi.git/tree/maven-plugins/README.md Maven plugins for signing artifacts]
 +
* [[IT_Infrastructure_Doc#Sign_my_plugins.2FZIP_files.3F|On demand signing tool]]
  
==Related Topics and Links==
+
== Deliverables ==
* [http://wiki.eclipse.org/EclipseLTS Long Term Support]
+
* [http://wiki.eclipse.org/Build_Technologies List of Build Technologies]
+
  
==Meeting Minutes==
+
Additionally to recommendation and infrastructure, the CBI also produces pieces of software that are meant to be commonly used by all Eclipse.org projects.
* [http://wiki.eclipse.org/CBI/Jan10_2012 January 10, 2012]
+
* [http://wiki.eclipse.org/CBI/Jan24_2012 January 24, 2012]
+
* [http://wiki.eclipse.org/CBI/Feb7_2012 February 7, 2012]
+
* [http://wiki.eclipse.org/CBI/March6_2012 March 6, 2012]
+
* [http://wiki.eclipse.org/CBI/Mar20_2012 March 20, 2012]
+
* [http://wiki.eclipse.org/CBI/Code_Sprint_April_11_2012 Code Sprint #1, April 11, 2012] - in Ottawa, Canada
+
* [http://wiki.eclipse.org/CBI/Apr17_2012 April 17, 2012]
+
* [http://wiki.eclipse.org/CBI/May1_2012 May 1, 2012]
+
* [http://wiki.eclipse.org/CBI/May15_2012 May 15, 2012]
+
* [http://wiki.eclipse.org/CBI/May29_2012 May 29, 2012]
+
* [http://wiki.eclipse.org/CBI/June12_2012 June 12, 2012]
+
* [wiki.eclipse.org/CBI/June26_2012 June 26, 2012]
+
  
==FAQ==
+
===CBI License bundle===
  
===What does the CBI build of the Eclipse platform do?===
+
We offer a P2 repository containing the org.eclipse.license bundle which is located at:
  
Answer: The CBI build of the Eclipse platform is intended to produce the same output as the PDE build, and thus facilitate packaging without noticeable change. The noticeable difference the CBI build of the platform makes is ease of use to build the platform. For example, the prototype has consistently demonstrated that a newcomer without prior experience can build the Eclipse platform with under 30 minutes of effort on a machine with a supported JDK & Maven.
+
    http://download.eclipse.org/cbi/updates/license/
  
 +
This URL is a composite P2 repo containing the license bundle.
  
===What is the link between CBI & LTS?===
 
  
Answer: The Long Term Support program is aimed at enabling organizations to support and maintain Eclipse software far into the future, for decades if needed. Part of the program enables maintenance committers working on behalf of the company to fix issues. Ensuring a very easy to use, very easy to maintain, and portable build was essential to the program. The fact that a build with these attributes also provides much benefit to the community was another good reason to do CBI.
+
If you are using Tycho you can add the p2 repo to the <repositories> section of your pom.xml file. Something similar to this:
  
 +
<source lang="xml">
 +
    <repository>
 +
      <id>license-feature</id>
 +
      <url>http://download.eclipse.org/cbi/updates/license/</url>
 +
      <layout>p2</layout>
 +
    </repository>
 +
</source>
  
===Won't CBI be kept behind a firewall at Eclipse?===
+
In any particular feature which you need the license you can use the usual feature.xml section:
  
Answer: No, the work done for CBI will be public and available and projects will be encouraged to leverage them. In the future, there may be some enhanced tools and features based on CBI designed to make Long Term Support (LTS) easier/more efficient/more effective. These might be available to members of the LTS working group only and enable a business model which supports the Eclipse Foundation.
+
<source lang="xml">
 +
<?xml version="1.0" encoding="UTF-8"?>
 +
<feature
 +
      id="org.eclipse.help"
 +
      label="%featureName"
 +
      version="2.0.0.qualifier"
 +
      provider-name="%providerName"
 +
      plugin="org.eclipse.help.base"
 +
      license-feature="org.eclipse.license"
 +
      license-feature-version="1.0.0.qualifier"/>
 +
....
 +
</source>
  
 +
===Signing tool===
  
===Will my project be forced to move to CBI?===
+
* [https://git.eclipse.org/c/cbi/org.eclipse.cbi.git/tree/maven-plugins/README.md Maven plugins for signing artifacts]
 +
* [[IT_Infrastructure_Doc#Sign_my_plugins.2FZIP_files.3F|On demand signing tool]]
  
Answer: No, there are no plans for forcing projects to use CBI. But if CBI develops the way we intend, you'll likely feel there's much good value to use it and decide to move to CBI on your own. Part of the benefit include the really easy to use & powerful build. Part of the benefit is that using CBI allows the Eclipse Foundation's release engineer to provide some assistance to ensure your project has a really good build. Another important part of the CBI initiative is a Continuous integration facility and build farm maintained by the Eclipse Foundation... so you don't need to create & maintain one yourself somewhere else.
+
=== p2 repo checks ===
  
 +
A set of "tests" which create reports or can be ran as unit tests that check to correctness of p2 repositories. That is partially just "correctness" in general (such as, that jars are signed, etc.) but more so that repositories conform to the requirements of the Eclipse Simultaneous release (such as, that jars have correct "Provider names", licenses, etc.). For more information, see See [[CBI/p2repoAnalyzers/Repo Reports]].
  
===Isn't this just yet-another-build system at Eclipse?===
+
=== p2 repo aggregator ===
 +
 
 +
A tool to combine several p2 repositories. Among other things, it makes sure they all have consistent constraints (that is, can be "installed together") unlike a raw p2 mirror task. For more information see [[CBI/aggregator/manual]].
 +
 
 +
==Related Topics and Links==
 +
* [[EclipseLTS|Long Term Support]]
 +
* [[Build_Technologies List of Build Technologies]]
 +
 
 +
==Resources==
 +
=== Mailing-list ===
 +
[https://dev.eclipse.org/mailman/listinfo/cbi-dev cbi-dev]
 +
 
 +
=== FAQ ===
 +
 
 +
* See your [[CBI/FAQ|Frequently Asked Question list]]
 +
 
 +
===Bugs===
 +
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap;product=CBI;version=1.0;list_id=2249872 CBI 1.0]
 +
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap;product=CBI;version=2.0;list_id=2249872 CBI 2.0]
 +
* [https://bugs.eclipse.org/bugs/buglist.cgi?action=wrap&product=CBI&list_id=38248 List of All Bugs] (Product = CBI)
 +
 
 +
===Tutorials, News, and other resources===
 +
* [http://www.vogella.com/articles/EclipseTycho/article.html Tycho tutorial by Lars Vogel]
 +
* [http://www.fosslc.org/drupal/content/tycho-good-bad-and-ugly Video discussing JBoss tools use of Tycho]
 +
* [http://wiki.eclipse.org/CBI/Workshops Workshops being developed]
 +
* [http://www.vogella.com/blog/2012/10/08/building-eclipse-sdk-locally-with-maven/ Building Eclipse SDK locally with Maven]
 +
* [http://mickaelistria.wordpress.com/2012/10/08/sonar-at-eclipse-org/ Sonar at Eclipse.org !]
 +
* [http://youtu.be/KJUfLvXiTSw Tycho and CBI Adoption: Feedback from the trenches]
 +
* [http://www.bsiag.com/scout/?p=678 Eclipse Scout builds with CBI]
 +
 
 +
 
 +
==Meetings==
 +
 
 +
=== Next Meeting ===
 +
See the [http://wiki.eclipse.org/CBI/Conference conference bridge details]. Contact andrew dot ross at eclipse dot org if you would like to be added to the Calendar reminder. The dates the upcoming calls are as follows:
 +
* November 15th, 9am EST
 +
 
 +
===Meeting Minutes===
 +
* [http://wiki.eclipse.org/CBI/Jan10_2012 January 10, 2012]
 +
* [http://wiki.eclipse.org/CBI/Jan24_2012 January 24, 2012]
 +
* [http://wiki.eclipse.org/CBI/Feb7_2012 February 7, 2012]
 +
* [http://wiki.eclipse.org/CBI/March6_2012 March 6, 2012]
 +
* [http://wiki.eclipse.org/CBI/Mar20_2012 March 20, 2012]
 +
* [http://wiki.eclipse.org/CBI/Code_Sprint_April_11_2012 Code Sprint #1, April 11, 2012] - in Ottawa, Canada
 +
* [http://wiki.eclipse.org/CBI/Apr17_2012 April 17, 2012]
 +
* [http://wiki.eclipse.org/CBI/May1_2012 May 1, 2012]
 +
* [http://wiki.eclipse.org/CBI/May15_2012 May 15, 2012]
 +
* [http://wiki.eclipse.org/CBI/May29_2012 May 29, 2012]
 +
* [http://wiki.eclipse.org/CBI/June12_2012 June 12, 2012]
 +
* [http://wiki.eclipse.org/CBI/June26_2012 June 26, 2012]
 +
* [http://wiki.eclipse.org/CBI/July25_2012 July 25, 2012]
 +
* [http://wiki.eclipse.org/CBI/November15_2012 November 15, 2012]
 +
* [http://wiki.eclipse.org/CBI/January8_2013 January 8, 2013]
  
Answer: In truth, many of the technologies involved with CBI such as Maven, Tycho, Hudson, Git, etc. were already in use by a number of projects who consider them to be best of breed. In addition, they were/are being considered by others. Thus in a way, CBI is an evolutionary effort building on momentum in the community. Technologies such as Maven and Nexus (the artefact storage repository often used with Maven) are ubiquitous and very popular.
+
[[Category:CBI]]

Revision as of 08:41, 4 May 2017

The Eclipse Common Build Infrastructure (CBI) is an initiative combining technologies and practices for building Eclipse Software.

What is CBI

The core of CBI today is Maven with the Tycho plugins. The Tycho plugins teach Maven how to build (and consume) Eclipse plugins and OSGi bundles. This enables building Eclipse projects with "maven clean install" just as one would build other Maven projects.

Common services such as the Jar signing facility, MacOS signing facility, and Windows signing facility are also included with CBI. Other tools and services may be included in the future as the need arises.

Over time mature templates and common pom.xml files will be provided that set common values finely honed with experience.

One might go so far as to include Git, Hudson/Jenkins, the build slaves, and Nexus (aka. the artifact repository & server side of Maven) as part of CBI since they are also common and crucial to builds.

Gerrit, Bugzilla, and the Downloads site are closely related. Some might consider them part of CBI as well.

Initiative Goals

Primary goals are:

  • Make it really easy to contribute Eclipse projects
    • Make it really easy to copy & modify source
    • Make it really easy to build
    • Make it really easy to test
    • Make it really easy to post a change for review
    • Make it really easy to sign software

Secondary goals are:

  • Get all Eclipse projects building their software on Eclipse Foundation hardware.
  • Enable the Long Term Support Program.
  • Make it easy for people to build custom Eclipse distributions.

There is a strong link between CBI and the Long Term Support Program which enables a marketplace of companies providing maintenance and support for Eclipse technologies for durations far beyond typical community support. Please NOTE: CBI features will be available to community.

It is our hope that this project develops an offering that is compelling so that many projects will move to use it.

Who is using it?

There's a list of projects building with CBI available. The Eclipse Foundation would like to have more than 50% of projects building with CBI by end of 2013.

Eclipse Platform Build is based on CBI see the CBI/Eclipse Platform Build Roadmap

Preferred Build Technologies

Hudson/Jenkins

Maven

Maven 3.0 drives the builds. Projects are expected to provide standard Maven 3.0 POM files for their builds. The builds should be built in such a way that they can be run on the local workstation, or on the Eclipse build server. Note that builds can only be signed on the Eclipse build server.

Tycho

Tycho is focused on a Maven-centric, manifest-first approach to building Eclipse plug-ins, features, update sites, RCP applications and OSGi bundles.

Helpful links:

p2 Repo checks

It's highly recommended that any Eclipse.org project runs frequently, and maybe even systematically, the p2 repo analyzer to make sure it conforms to some requirements of being a nice citizen in the Eclipse.org world.

Nexus

Services/Nexus

Signing tool

Deliverables

Additionally to recommendation and infrastructure, the CBI also produces pieces of software that are meant to be commonly used by all Eclipse.org projects.

CBI License bundle

We offer a P2 repository containing the org.eclipse.license bundle which is located at:

   http://download.eclipse.org/cbi/updates/license/

This URL is a composite P2 repo containing the license bundle.


If you are using Tycho you can add the p2 repo to the <repositories> section of your pom.xml file. Something similar to this:

    <repository>
      <id>license-feature</id>
      <url>http://download.eclipse.org/cbi/updates/license/</url>
      <layout>p2</layout>
    </repository>

In any particular feature which you need the license you can use the usual feature.xml section:

<?xml version="1.0" encoding="UTF-8"?>
<feature
      id="org.eclipse.help"
      label="%featureName"
      version="2.0.0.qualifier"
      provider-name="%providerName"
      plugin="org.eclipse.help.base"
      license-feature="org.eclipse.license"
      license-feature-version="1.0.0.qualifier"/> 
....

Signing tool

p2 repo checks

A set of "tests" which create reports or can be ran as unit tests that check to correctness of p2 repositories. That is partially just "correctness" in general (such as, that jars are signed, etc.) but more so that repositories conform to the requirements of the Eclipse Simultaneous release (such as, that jars have correct "Provider names", licenses, etc.). For more information, see See CBI/p2repoAnalyzers/Repo Reports.

p2 repo aggregator

A tool to combine several p2 repositories. Among other things, it makes sure they all have consistent constraints (that is, can be "installed together") unlike a raw p2 mirror task. For more information see CBI/aggregator/manual.

Related Topics and Links

Resources

Mailing-list

cbi-dev

FAQ

Bugs

Tutorials, News, and other resources


Meetings

Next Meeting

See the conference bridge details. Contact andrew dot ross at eclipse dot org if you would like to be added to the Calendar reminder. The dates the upcoming calls are as follows:

  • November 15th, 9am EST

Meeting Minutes

Back to the top