Difference between revisions of "OCL/Dev/Releng/Issues Documentation"

Revision as of 08:34, 2 July 2012

This wiki entry has been created in order to document specific releng-related issues, final diagnosis, and how they were solved.

No component named ... is known to Buckminster

Date: 01/02/2012.

Problem: Juno M5 S-build failed due to the following error:

INFO: perform '--properties' '/opt/users/hudsonbuild/workspace/buckminster-mdt-ocl-tools-3.2-master/buildroot/build.properties' '-Dbuckminster.reference.repository=https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-tools-3.2-master/lastSuccessfulBuild/artifact/MDT-OCL.p2.repository/' 'org.eclipse.ocl.releng.tools.build:eclipse.feature#build' No component named org.eclipse.ocl.doc.source:eclipse.feature/[3.1.0.v20111215-0955,3.1.0.v20111215-0955] is known to Buckminster

This only occurred with OCL Tools S-build. Nightly and Integration builds worked. OCL Core S-Build succed as well.

Diagnosis:

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:

Replace:

<rm:locator pattern="^org\.eclipse\.ocl.*$" searchPathRef="ocl-core" failOnError="false"/>

By:

<rm:locator pattern="^org\.eclipse\.ocl(\.(ecore|uml|all|core\.sdk))?(\.source)?$" searchPathRef="ocl-core"/>

Commit bfed05ba761eeaf6e090b6e0e86e096509c0545c

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:

Replacing:

<rm:locator pattern="^com\.google.*" searchPathRef="xtext"/>

By:

<rm:locator pattern="^com\.google.(inject|guava)$" searchPathRef="xtext"/>

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.

Solution:

Reinstate the failOnError = false property into the ocl-tools.rmap:

<rm:locator pattern="^org\.eclipse\.ocl(\.(ecore|uml|all|core\.sdk))?(\.source)?$" searchPathRef="ocl-core" failOnError="false"/>

Commit 3d2aec2dc6fb7c0840fbe3d45428254e79e1f72d

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.

I moved the question to cross project [3] with no responses so far.

[1] [ant] Packaging site: mdt-ocl-Update INFO: [end org.eclipse.ocl.releng.tools.build:eclipse.feature$1.0.0.qualifier#package.mdt-ocl-Update] INFO: [start org.eclipse.ocl.releng.tools.build:eclipse.feature$1.0.0.qualifier#site.tp] INFO: [end org.eclipse.ocl.releng.tools.build:eclipse.feature$1.0.0.qualifier#site.tp] INFO: [start org.eclipse.ocl.releng.tools.build:eclipse.feature$1.0.0.qualifier#package.mdt-ocl-SDK] ERROR: org.eclipse.core.runtime.CoreException: <https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-branch-tests/ws/org.eclipse.ocl.git/releng/org.eclipse.ocl.releng.tools.build-feature/packaging.ant>:208: Java returned: 13 org.eclipse.core.runtime.CoreException: <https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-branch-tests/ws/org.eclipse.ocl.git/releng/org.eclipse.ocl.releng.tools.build-feature/packaging.ant>:208: Java returned: 13 at org.eclipse.buckminster.ant.AntRunner.handleInvocationTargetException(AntRunner.java:167) at org.eclipse.buckminster.ant.AntRunner.run(AntRunner.java:322) at org.eclipse.buckminster.ant.actor.AntActor.internalPerform(AntActor.java:254) at org.eclipse.buckminster.core.actor.AbstractActor.perform(AbstractActor.java:195) at org.eclipse.buckminster.core.internal.actor.PerformManager$DirectActionInvocation.execute(PerformManager.java:143) at org.eclipse.buckminster.core.internal.actor.PerformManager.internalPerform(PerformManager.java:454) at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:293) at org.eclipse.buckminster.core.internal.actor.PerformManager.perform(PerformManager.java:305) at org.eclipse.buckminster.core.commands.Perform.internalRun(Perform.java:108) at org.eclipse.buckminster.core.commands.WorkspaceCommand.run(WorkspaceCommand.java:91) at org.eclipse.buckminster.cmdline.AbstractCommand.basicRun(AbstractCommand.java:200) at

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=294440

[3] http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg07517.html

Solution: Not resolved yet.