For S-builds, we are using our own miletones repository to feed our Tools components with the Core ones.

During this milestone development, doc (and other features) were "restructured", so that they were previously built as OCL Core components, and they are currently built as OCL Tools components. So, In a Tools build, they are supposed to be materialized into the workspace. However, after deeply analyzing the job's console and workspace, I've realized that these features are being materialized into the target platform.

My current rmap is configured so that every OCL feature/plugin from a provided repository (tipically, a repository with Core componentes), is installed in the target platform, and the remaining are supposed to be materialized into the workspace from our GIT repository.

For Nightly and Integration builds, the repository from our Core job is used so just the expected Core components are installed into the target platform, hence, the doc plugin and feature is materialized into the workspace, and no problem with sources features.

For Stable builds, our milestones repository is used. However, it's a composed repository which also composes repositories from previous releases. Unfortunately, this means that non-Core plugins and featres (for example, doc ones) are available (from a repository of a previous milestone) and so installed into the target platform. Obviously this is incorrect and provokesthat they can't be materialized into the workspace and therefore no source feature is generated for them.

Solution:

To solve this, I think that I'll definitelly specify in the tools.rmap a locator whose pattern binds to the specific set of features/plugins which are expected for Core components. So the change is the following:

No suitable provider for component com.google.collect... was found in resourceMap file

Date: 06/02/2012

Problem: Tests job fails due to an unresolved com.google.collect bundle

ERROR [0087] : No suitable provider for component com.google.collect:osgi.bundle/1.0.0 was found in resourceMap file:/opt/users/hudsonbuild/workspace/buckminster-mdt-ocl-branch-tests/org.eclipse.ocl.git/releng/org.eclipse.ocl.releng.buckminster/releng/ocl-tools.rmap
ERROR [0087] : No suitable provider for component com.google.collect:osgi.bundle/1.0.0 was found in searchPath xtext
ERROR [0087] : Rejecting provider p2({0}/modeling/tmf/updates/nightly[file:/home/data/httpd/download.eclipse.org/modeling/tmf/updates/nightly]): No component match was found

Diagnosis:

Every com.google.* bundle is being resolved against the Xtext repository, which is redistributing such a bundles. Since Xtext is not using such a bundle (guava is used instead), they are not distributing it anymore. However, due to an acceleo dependency, our build requires com.google.collect bundle. This bundle is distributed in the Orbit repository.

Solution:

Narrowing which com.google* bundles are fetched from Xtext. In this case every bundle distributed by Xtext which is not present into the Orbit repository:

N.B: Another interesting question is why Xtext is distributing such a third party bundle and it's not in the Orbit repository. I believe that we should fetch these bundles from Orbit repository.

Commit 3d2aec2dc6fb7c0840fbe3d45428254e79e1f72d

Attempt to use an unresolved node.

Date: 01/02/2012.

Problem: Tests job failed due to the following error:

ERROR: Attempt to use an unresolved node. Request is org.eclipse.ocl.uml:osgi.bundle/[4.0.0,5.0.0)

org.eclipse.buckminster.core.metadata.model.UnresolvedNodeException: Attempt to use an unresolved node. Request is org.eclipse.ocl.uml:osgi.bundle/[4.0.0,5.0.0)

Diagnosis:

When solving the problem in comment 1, I naively assumed that when specifying a concrete set of CORE components to be fetched in a Tools build, if the component is not found in the ocl-core search path, such a build must fail. I completely forgot the tests build which also uses the ocl-tools cquery and rmap files. The "resolve.ocl.core" property guides the build to resolve, otherwise not resolve, the OCL Core components from our p2 repositories. Therefore, when solving Core components in such a Search Path, the failOnError must be false, so that the tests build may later fetch OCL Core components from our GIT repository and materialize them into the job's workspace.

Packaging site

Date: 14/04/2012

Problem: Tests build failed due to an error [1] during the OCL SDK packaging. This error had previously appeared (Bug 363208 comment 2) and it's related to the process of packaging the zips, recently solved in that bug.

Diagnosis:
The main inconvenience with the issue is that the Job's console doesn't provide any useful information about the problem. This can me investigated in local by adjusting the ANT logger level set by buckminster : Windows -> Preferences -> Buckminster -> Ant logger level = DEBUG. However in local the SDK zip packaging worked well so I can't reproduce the failed process in debug mode.

I've found a link[2] which shows how to change the ANT logger level for buckminster headless. Unfortunately, buckminster application commands are configured in hudson, vi its web UI (by the means of hudson-buckminster plugin) and there was not way to configure that in hudson web UI.

One occasion the problem may have been caused by temporarily changing a launch configuration to use explicitly nominated plugins and then reverting. It may be that the obsolete but retained selections in the config cause trouble. This was cure by precisely reverting to the original launch configuration.