Development Resources/IP/Test and Build Dependencies

From Eclipsepedia

Jump to: navigation, search
Important.png
Draft
This is a draft document; please confirm with EMO.


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).

Note that this document applies specifically to open-source libraries and tools only; itdoes 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 URL's in Eclipse will cause the user's configured web browser to open the URL.

To declare test dependencies, use the Development Portal to create a new CQ for your project:

  • Select [request] to use, reference, or distribute third-party code that is maintained elsewhere (not already in Orbit)
  • Follow the workflow to [enter] a new CQ for the third-party code because none of the previously approved CQs are a good match
  • 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).

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.