Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] p2 <-> aggregator sync.

Meanwhile I could reproduce David's observation after getting me a
fresh simrel workbench via Oomph.

As requested by Todor, I filed
which also has some details about the requirements causing the failure.

Contrary to Ed's guess, the repo in question was indeed produced
by the exact version of p2 as contributed to M5. (My builds always
start with: download latest SDK milestone and use that to drive
the build).

If p2 @ M5 is not ready for prime time (as Ed's reluctance suggests)
then I may have no other chance but to pull Object Teams out of simrel
for now.

Is everybody else still using Oxygen's p2 to create their contribution?
But then: when and how will the latest p2 be tested in real-life scenarios?

BTW: did anyone find out how to get more meaningful logs from
failed gerrit builds / aggregations?


PS: Todor, I understand that your current task is far from trivial
and legacy weighs heavy on you.

On 29.01.2018 11:04, Todor Boev wrote:
Please open a bug for this.

The issue seems to come from:

The expression in the repository is *not* a generic requirement. It is the internal representation of a *standard* "namespace; name; version-range". Both standard and generic requirements have similar internal representations with a complex match expressions like this. The p2 read/write code always had this hack to guess if the requirement it is about to write is standard or general. The guess is inherently unreliable. To that hack I added one more guess for a properties match requirement.

I am not sure how but the guessing code for standard requirements failed in this instance.

P2 would have been much better off if it just wrote it's requirements in their normal expression language form. Instead it first introduces a very general expression language that is opaque to external readers (because it is so general) and then tries to hack itself by guessing what kind of expression this is.

My impression was that the latest design idea was to not serialize the
more general "match" requirements in a form that older runtimes would
even read them, so they would not be represented as an
RequiredCapability at all and not be serialized in a form that older
runtimes would even loaded, so would be invisible in order runtimes.
But perhaps this repo was produced with an M4 version of p2 and not
the current version that's in the 4.8IBuilds.

On 29.01.2018 08:37, David Williams wrote:

On 01/28/2018 12:48 PM, Stephan Herrmann wrote:

Result [2]:
Unable to load repository
p2:file:///home/data/httpd/ <>
While I don't see the actual root error, this appears to be the case
were the aggregator cannot handle current format of p2 meta data.
(Any chance to access any details of this failure?)

Did you try the aggregator editor?
I can see some detail in the console log, when using the aggregator editor.
This is with Oxygen.2 and aggregator 4.7 installed.
The log says "can not load repository" (as does pop up dialog), but
then the log continues with
!MESSAGE Unable to load repository <>
     at org.eclipse.equinox.internal.p2.metadata.RequiredCapability.assertValid(
     at org.eclipse.equinox.internal.p2.metadata.RequiredCapability.extractRange(
     at org.eclipse.equinox.internal.p2.metadata.RequiredCapability.getRange(
     at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(
     at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(
     at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(
     at org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(
     at org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(
     at org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(

And, from looking at the code, there is something about (p2's)
"getVersion" that p2 considers invalid -- that is, while processing
your version in your required capability data. Only in the Oxygen
stream, that I see.

In my dev. environment where Photon M5 is installed, and the
aggregator built from master branch, (i.e. installed from
then there is no exception, and no problem. But, I do not know if it
produces what you intend.

In the Oxygen branch, I put in some debug statements, ran locally, and
it is chocking on the capabilities involved with
org.eclipse.objectteams.otequinox.branding, perhaps this part:

<requires size='6'>
          <requiredProperties namespace=' <>' match='(&amp;( <>=JavaSE)(version=1.7))'/>
          <required namespace='osgi.bundle' name='org.eclipse.ui' range='[3.7.0,4.0.0)'/>
          <required namespace='osgi.bundle' name='org.eclipse.ui.workbench' range='[3.7.0,4.0.0)'/>
          <required namespace='osgi.bundle' name='org.eclipse.objectteams.otequinox' range='[2.3.0,3.0.0)'/>
         <required match='providedCapabilities.exists(cap | <> == $0 &amp;&amp; cap.namespace == $1 &amp;&amp; cap.version ~= $2)' matchParameters='[&apos;org.eclipse.objectteams.otequinox.branding&apos;, &apos;org.eclipse.equinox.p2.iu&apos;, range(&apos;[2.5.0,3.0.0)&apos;)]' min='0' max='0'/>
          <required namespace='osgi.bundle' name='org.eclipse.core.runtime' range='[3.7.0,4.0.0)'/>

So, how many others are going to have *that* sort of match statement
and that sort of problem? :)

IMHO, at least for M5 and Oxygen.3, the Oxygen update branch of Sim
Release should still be aggregated with a base of Oxygen.2 and

whereas the Photon branch of Sim Release should be aggregated with
Photon M5 and ...cbi/updates/aggregator/ide/4.8/
Can always revert back to Oxygen version if something goes terrible wrong.

But, I would be the last to have any true insight into current issues.
I have not been following all the detail requirements of why
"capabilities" is being changed in the way it has been so do not know
the use cases or motivations for the change.
I assume no one needs a change for Oxygen updates.

cross-project-issues-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top