|
|
|
Re: Converting a target definition file to targlets results in an artificial_root node error [message #1818102 is a reply to message #1818100] |
Thu, 05 December 2019 23:39 |
Ed Merks Messages: 33141 Registered: July 2009 |
Senior Member |
|
|
Note that if you copy something in the Setup editor and paste it into the forum, then I can copy that text and paste it into my setup editor. That's a lot less work than trying to reproduce the parts of your sample.
So I just tried this:<?xml version="1.0" encoding="UTF-8"?>
<setup.targlets:TargletTask
xmi:version="2.0"
xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:setup.targlets="http://www.eclipse.org/oomph/setup/targlets/1.0"
xsi:schemaLocation="http://www.eclipse.org/oomph/setup/targlets/1.0 http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/models/SetupTarglets.ecore">
<targlet name="Test">
<requirement
name="org.eclipse.equinox.sdk.feature.group"/>
<requirement
name="org.eclipse.platform.sdk"/>
<repositoryList>
<repository
url="http://download.eclipse.org/releases/latest"/>
<repository
url="http://download.eclipse.org/tools/orbit/downloads/drops/R20190226160451/repository"/>
</repositoryList>
</targlet>
</setup.targlets:TargletTask>
I.e., I used Navigate -> Open Setup -> Workspace and created this task there, and then performed just that task in the usual way, but that works for me.
Your failure is kind of odd, because it's not a resolution failure but rather a failure to find the artifact corresponding to the properly resolved IU. That can only happen if the content metadata and the artifact metadata are inconsistent, or if the artifact metadata could not be loaded.
Of course that artifact definitely exists. It's in the report:
https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2019-09/http___download.eclipse.org_releases_2019-09_201909181001/org.eclipse.platform.source_4.13.0.v20190916-1045.html
And it can only be in the report if the repository is in a consistent state.
And of course it works for me.
One thing you could try is to remove p2's own cache (which uses obscure names that you can't map back to where the cached files came from):
~/.p2/org.eclipse.equinox.p2.repository/cache
And Oomph's p2 cache (which uses names based on the URI from which the data is downloaded):
~/.eclipse/org.eclipse.oomph.p2/cache
A detailed analysis of these caches could help understand what was actually delivered by the server and used to find the artifacts. Something seems to be wrong with one of these:
http___download.eclipse.org_releases_2019-09_compositeArtifacts.jar
http___download.eclipse.org_releases_2019-09_201909181001_artifacts.xml.xz
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.03726 seconds