Development Resources/IP/Test and Build Dependencies

Test and build dependencies are those third-party libraries and tools that are considered non-distribution contributions. That is, these libraries are not actively distributed by the project via any generally-accessible eclipse.org property. These libraries and tools may, for example, persist on the build server which is accessible only to Eclipse committers; they may not, for example, persist on the eclipse.org download or archive servers, web server, or any source code repository. Eclipse project code and scripts that are distributed via eclipse.org source code repositories may contain references to these libraries and tools (but not the libraries/tools themselves). Project documentation should list these dependencies, how they are obtained (either manually or automatically via scripts), and other issues (especially licensing).

This document only applies to dependencies that are required exclusively to facilitate build and test. Any dependencies that are required by downstream consumers of the Eclipse software (i.e. they are pre-requisite dependencies as defined by the Guidelines for the Review of Third-party Software) must be entered individually in separate CQs. This document applies specifically to open-source libraries and tools only; it does not apply to the use of proprietary tools. Use of proprietary tools is covered by Board resolution.

Test and build dependencies may be grouped together in a single contribution questionnaire (CQ) declared as a "works with" dependency based on the first definition in the Guidelines for the Review of Third-party Software:

The Eclipse software does not require the third party software to be present. If the third party software happens to be present, the Eclipse software may call or invoke it. Example: If a web browser is present, clicking on URLs in Eclipse will cause the user's configured web browser to open the URL.

To declare test dependencies, use the Project Management Infrastructure to [a new CQ] for your project:

• Enter a title containing the terms test-only dependencies, build-only dependencies, or build- and test-only dependencies (or something like that).
• Enter a description that indicates that the CQ is for test/build-only dependencies, and a request to declare the dependencies as "works with" lists all the third-party dependencies--one on each line--along with version information; e.g.

This is an umbrella CQ for all dependencies of the Tycho
project which are only needed to compile and execute unit and integration tests
for Tycho. 

These artifacts are *not* redistributed by the Tycho project and are strictly
only needed to compile and run tests for tycho itself. 

The following bundles from orbit are required by tycho as test-only
dependencies:

Bundle-SymbolicName : Bundle-Version
=============================================
com.ibm.icu:4.2.1.v20100412
javax.xml:1.3.4.v201005080400
org.apache.ant:1.7.1.v20090120-1145
org.junit:3.8.2.v20080602-1318
org.junit:3.8.2.v20090203-1005

(note that, if the list is long, it might be easier to include it in a comment after the CQ is created)

• Make your best guess for the License, Source/Binary, and other fields. These cannot be blank, but there is likely no one exact right entry (if there are multiple licenses included, type "various" in the field provided).

You can create multiple test and build CQs (i.e. you don't have to get this exactly right the first time).

At the PMC's discretion, you can specify version ranges (or just "*" or "all versions").

You may receive one or more requests to attach source code to the CQ. Ignore these requests.

Test-only dependencies must not be checked into Eclipse SCM in any form. They must also not be distributed from download.eclipse.org.

You will need PMC approval. You may be able to hasten approval if you work with your PMC prior to creating the CQ to ensure that they understand your requirements.

If you have any questions or concerns, please contact EMO.

This page is moderated by the EMO.