Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Problems setting up CDT using Oomph

Thanks a lot Jonah for narrowing this down! I will be following the bug you created.
In the mean time, I added the bouncycastle dependencies explicitly with exact version so that it works. I also added a missing dependencies, see https://git.eclipse.org/r/#/c/68187/

As for re-using the cdt.target file in the Oomph setup, it's possible but when you do that you lose the possibility to combine with other Oomph setups because there can be only one active .target at a time whereas targlets can be combined.

Marc-Andre


From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Jonah Graham [jonah@xxxxxxxxxxxxxxxx]
Sent: Thursday, 10 March 2016 4:36 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Problems setting up CDT using Oomph

Actually I think I have found there is a bug in resolving target platform against https://hudson.eclipse.org/orbit/job/orbit-recipes/lastSuccessfulBuild/artifact/releng/repository/target/repository URL. 

A simple target platform that only contains org.bouncycastle.bcprov-jdk15on such as:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<?pde version="3.8"?><target name="mytarget" sequenceNumber="0">
<locations>
<location includeAllPlatforms="false" includeConfigurePhase="true" includeMode="planner" includeSource="true" type="InstallableUnit">
<unit id="org.bouncycastle.bcprov-jdk15on" version="1.52.0.v20160229-0929"/>
</location>
</locations>
</target>

does fail all by itself in a clean workspace. It also fails to download with the p2 browser https://github.com/ifedorenko/p2-browser.

Now the above is a bug in the repo or p2, don't know which, don't even know how to tell. I have filed bug 489387 against Orbit as a starting point.

So on to why it fails in Oomph but not in cdt.target? In Oomph cdt.setup simply provides a list of features + a list of repos (URLs) to get those features and their dependencies from. However cdt.target limits each of the target locations to just specific contents.

So here is where the difference comes in. Not cdt.target and cdt.setup have org.eclipse.linuxtools.docker.feature listed as a dependency. In all the locations in cdt.setup/cdt.target there are two different bouncycastles. One in Docker's update site (v 1.51 in http://download.eclipse.org/linuxtools/updates-docker-nightly/plugins/?d) and one in Orbit Recipes (v 1.52 in https://hudson.eclipse.org/orbit/job/orbit-recipes/lastSuccessfulBuild/artifact/releng/repository/target/repository). 

So because cdt.target only allows a few of the bundles in Orbit Recipes the v 1.51 version is simply downloaded with no fuss.



~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

On 10 March 2016 at 20:17, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
OK, after approximately 30 minutes I gave up waiting with no apparent progress. I tried resolving the target platform (/org.eclipse.cdt.target/cdt.target) manually in the Oomph created install/workspace and that didn't work either.

In my primary dev eclipse install I deleted by bundle pool (rm -rf ./.metadata/.plugins/org.eclipse.pde.core/.bundle_pool) and press "Set as Target Platform" in cdt.target and it worked fine downloading everything again. 

To me this means that some of the shared bundle pooling in Oomph may be getting in the way, but of course the earlier failure may lead to a broken state that I don't yet know how to clear up. It may also be related to Mars.1 (my primary dev eclipse install that I have not upgraded yet) vs. Mars.2 (the oomph created one)

A thing to note, CDT.setup's Targlets is not based on cdt.target. The setup file has not been updated (by me and others) when changes are made to the cdt.target. Therefore it may not deliver a working target platform anyway :-( 

If anyone does get it working reliably in Oomph I would be interested to hear. Unfortunately for now I have simply not taken the time to debug the Oomph issues more than above.

Jonah



~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

On 10 March 2016 at 19:22, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Hi Jesper,

It might not be the confrence venue's fault. I have run the oomph CDT process as Marc D linked to. It all downloaded and installed Mars fine, clone cdt, downloaded tp, but now it is stuck apparently on hudson.

It has been chewing 100% CPU for 10 minutes or so, so I think it has failed, I will leave it in case it magics itself :-)

This is the end of the log:

Calculating requirements and dependencies.
Computing prerequisite plan
Fetching compositeArtifacts.xml from http://download.eclipse.org/tm/updates/4.0/
Fetching compositeArtifacts.jar from http://download.eclipse.org/cbi/updates/license/
Downloading org.antlr.runtime
Downloading org.slf4j.api.source
Downloading org.bouncycastle.bcprov-jdk15on.source
Downloading org.antlr.runtime.source
Downloading org.slf4j.api
Downloading org.freemarker.source
Downloading org.bouncycastle.bcprov-jdk15on
Downloading org.freemarker
Checking…
40 KB/3 MB
80 KB/3 MB
121 KB/3 MB
161 KB/3 MB
201 KB/3 MB
242 KB/3 MB
282 KB/3 MB
322 KB/3 MB
363 KB/3 MB
403 KB/3 MB
444 KB/3 MB
484 KB/3 MB
524 KB/3 MB
565 KB/3 MB
605 KB/3 MB
645 KB/3 MB
686 KB/3 MB
726 KB/3 MB
766 KB/3 MB
807 KB/3 MB
847 KB/3 MB
888 KB/3 MB
928 KB/3 MB
968 KB/3 MB
1009 KB/3 MB
1 MB/3 MB
2 MB/3 MB
3 MB/3 MB
Replacing local database

~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com

On 10 March 2016 at 16:11, Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx> wrote:
Hi Jesper,

When I tried it, it got stuck on org.bouncycastle (dependency of Docker I believe). It might also be because of the EclipseCon wifi. I'll look into it when I get a more stable connection. Perhaps someone with a good connection could try it in the mean time?

Marc-Andre

________________________________________
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Jesper Eskilson [Jesper.Eskilson@xxxxxxx]
Sent: Wednesday, 09 March 2016 3:17 PM
To: CDT General developers list.
Subject: [cdt-dev] Problems setting up CDT using Oomph

Hi people,

I'm trying to use Oomph to setup a CDT environment, but Oomph keep getting stuck when downloading stuff for its target platform. The exact place it gets stuck seems to vary from time to time, but for example here:

Fetching org.antlr.runtime.source_4.5.1.v20160210-1233.jar from https://hudson.eclipse.org/orbit/job/orbit-recipes/lastSuccessfulBuild/artifact/releng/repository/target/repository/plugins/

I'm sitting with the EclipseCon wifi at the moment, so maybe that is a problem. Anyone else seeing this? I'd hate having to go back to setting up my CDT workspace manually. :)

/Jesper
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev




Back to the top