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/download.eclipse.org/objectteams/updates/ot2.7/staging
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 http://download.eclipse.org/objectteams/updates/ot2.7/staging
!STACK 0
java.lang.IllegalArgumentException
at
org.eclipse.equinox.internal.p2.metadata.RequiredCapability.assertValid(RequiredCapability.java:271)
at
org.eclipse.equinox.internal.p2.metadata.RequiredCapability.extractRange(RequiredCapability.java:250)
at
org.eclipse.equinox.internal.p2.metadata.RequiredCapability.getRange(RequiredCapability.java:164)
at
org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:458)
at
org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:342)
at
org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:280)
at
org.eclipse.cbi.p2repo.p2.util.P2Bridge.importToModel(P2Bridge.java:402)
at
org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:120)
at
org.eclipse.cbi.p2repo.p2.loader.impl.P2RepositoryLoader.load(P2RepositoryLoader.java:60)
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
...cbi/updates/aggregator/ide/4.8/
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='osgi.ee'
match='(&(osgi.ee=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 |
cap.name == $0 && cap.namespace == $1
&& cap.version ~= $2)'
matchParameters='['org.eclipse.objectteams.otequinox.branding',
'org.eclipse.equinox.p2.iu',
range('[2.5.0,3.0.0)')]' min='0' max='0'/>
<required namespace='osgi.bundle'
name='org.eclipse.core.runtime' range='[3.7.0,4.0.0)'/>
</requires>
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
...cbi/updates/aggregator/ide/4.7/
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
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|