Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] Build failed : how to ensure a required dependency is used in the orbit-recipes build? (was Change 78687 in orbit/orbit-recipes[master]: [499378] Add Apache XML RPC 3.1.3)

> I have tried to specify the required version (3.0.1 or higher) for an
> Import-Package statement on org.apache.commons.httpclient, in my recipe for
> org.apache.xmlrpc.client.
> 
> Before there was no version set, and the build worked for the Gerrit push.
> 
> But with the version, the build shows a success first :
> 
> ...
> [INFO] Apache XML-RPC Client Library ...................... SUCCESS [  0.535
> s]
> [INFO] Apache XML-RPC Common Library ...................... SUCCESS [  0.530
> s]
> [INFO] Apache XML-RPC Server Library ...................... SUCCESS [  0.525
> s]
> 
> ...

Yes, because this part of the build merely attempts to create the bundles. The
default behaviour seems to be resolution:="optional"' for all import-packages,
so the bundle will likely always resolve. It's up to the committer to configure
the osgi.bnd file to specify which dependencies are mandatory.

I always thought it was a bit strange to have this on by default but maybe
something we can discuss for the future.


> but in the install build after this, there is a failure :
> [INFO] Computing target platform for MavenProject:
> org.eclipse.orbit.bundles:org.eclipse.orbit.releng.recipes.feature.aggregation:1.0.0-SNAPSHOT
> @
> /jobs/genie.orbit/gerrit-orbit-recipes/workspace/releng/aggregationfeature/pom.xml
> [INFO] Resolving dependencies of MavenProject:
> org.eclipse.orbit.bundles:org.eclipse.orbit.releng.recipes.feature.aggregation:1.0.0-SNAPSHOT
> @
> /jobs/genie.orbit/gerrit-orbit-recipes/workspace/releng/aggregationfeature/pom.xml
> [INFO] {osgi.os=*, osgi.ws=*, org.eclipse.update.install.features=true,
> osgi.arch=*}
> [ERROR] Cannot resolve project dependencies:
> [ERROR]   Software being installed:
> org.eclipse.orbit.releng.recipes.feature.aggregation.feature.group
> 1.0.0.qualifier
> [ERROR]   Missing requirement: org.apache.xmlrpc.client 3.1.3.v20160814-1533
> requires 'package org.apache.commons.httpclient 3.0.1' but it could not be
> found
> [ERROR]   Cannot satisfy dependency:
> org.eclipse.orbit.releng.recipes.feature.aggregation.feature.group
> 1.0.0.qualifier depends on: org.apache.xmlrpc.client [3.1.3,3.1.4)

My guess is as soon as you removed the resolution:=optional statements from the
osgi.bnd files, building the feature plugin meant those dependencies had to be
resolved. We don't seem to specify a reference to the old style p2 repos from
CVS so that's probably why this failed.

> 
> 
> This makes me wonder how the build finds the dependencies it needs for its
> target platform.
> I could not find any detailed dependencies in the poms, so I'm assuming the
> Tycho build checks the MANIFESTs to determine the required dependencies.
> But I also could not find the spec of the target platform, p2 repos or so.

Yes, it seems that the target platform configuration for Tycho has no p2
repositories configured so if the dependency isn't part of the project,
it will fail.

I think the reason we only started running into this now is because a lot of the
contributions were using "resolution:=optional" and also because contributions can 
be made without adding plugins to the feature itself (although then they would
never be in the final repository).

> Is there some setting somewhere to use an Orbit build as repo? The required
> bundle (org.apache.commons.httpclient) is documented as being part of
> Orbit...
> What is the approach to add dependencies to the orbit.recipse build, that are
> not themselves in the recipes?
> Or am I making another error altogether here?

I'll try adding a reference to the Neon R-build from Orbit. This is reasonable
because that content doesn't exist in orbit-recipes but are valid bundles to
use in dependency resolution. Once I resolve this, I'll rebase your change and
that should fix it.


Cheers,
-- 
Roland Grunberg


Back to the top