Community
Participate
Working Groups
Build Identifier: We have some problems with target definitions and headless buckminster. The following target definition resolves in my IDE but does not resolve in buckminster headless (ie the .bundle_pool contains no plugins and no features). I don't know why. One of the problems is, that there is no error message: > buckminster -L debug -data ws importtarget -A file:///test/test.target importtarget '-A' 'file:///test/test.target' Doing full workspace refresh Waiting for jobs to end > In the log file we can see the same information as on the console. Here's the minimized example target that is not working: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <?pde version="3.6"?> <target name="Target Platform for the funtrade BEI"> <locations> <location includeAllPlatforms="true" includeMode="slicer" type="InstallableUnit"> <unit id="org.eclipse.platform.sdk" version="3.6.0.I20100608-0911"/> <repository location="http://download.eclipse.org/releases/helios/"/> </location> </locations> </target> Reproducible: Always
I tried all this in the helios versions of buckminster and IDE.
Created attachment 172583 [details] The target that didn't resolve
I'm having this same issue. It grabs an apparantly random selection of plugins to .buckminster/tp from may target platform then nada. I'm using headless build.
Here's one example of what I'm referring to above: .buckminster/tp/plugins includes: org.jface.text but not: org.jface This doesn't make any sense.
By the way, as a work-around (and not a bad all around approach actually) I followed Martin Taal's idea and created a separate build for the target platform. For whatever reason, that seems to resolve this issue.
Peter, I think the latest Buckminster (published yesterday) fixes your issue. I've tried you attached target platform and it seems to resolve OK. Can you please give it a try? Miles, I'm not sure that what you're experiencing is the same problem. A test case with a target platform definition would be helpful.
(In reply to comment #6) > Peter, I think the latest Buckminster (published yesterday) fixes your issue. > I've tried you attached target platform and it seems to resolve OK. Can you > please give it a try? I tried and had the same results as above (nothing materialized & no error message). I'm not sure if I tested the right version; I took the director_latest.zip and used the http://download.eclipse.org/tools/buckminster/headless-3.6 update site. Is that OK?
This is what I do: 1. I use the director to install a fresh headless buckminster from the headless-3.6 site (the one you mention). I install the core.headless and pde.headless features. 2. I run the command that you mention in comment 1. 3. After it has completed (this takes several minutes), I look at: ws/.metadata/.plugins/org.eclipse.pde.core/.bundle.pool/ I find an artifacts.xml and a features/ and plugins/ directory. Fully populated according to the target. Is there any difference in how we test this?
No, that's exactly what I did. Here is some version information director output: - Installing org.eclipse.buckminster.cmdline.product 1.2.0.r11425. buckminster plugins: org.eclipse.buckminster.ant_1.2.360.r11210 org.eclipse.buckminster.cmdline_1.0.350.r11425.jar org.eclipse.buckminster.core_1.2.361.r11499.jar org.eclipse.buckminster.download_1.1.0.r11379.jar org.eclipse.buckminster.executor_1.0.0.r11341.jar org.eclipse.buckminster.fetcher_1.0.0.r11210.jar org.eclipse.buckminster.generic_1.0.0.r11210.jar org.eclipse.buckminster.installer_1.1.0.r11336.jar org.eclipse.buckminster.jarprocessor_1.0.0.r11295.jar org.eclipse.buckminster.jdt_1.0.0.r11394 org.eclipse.buckminster.junit_1.0.0.r11240.jar org.eclipse.buckminster.osgi.filter_1.0.0.r11266.jar org.eclipse.buckminster.pde_1.2.1.r11498 org.eclipse.buckminster.runtime_1.2.0.r11375.jar org.eclipse.buckminster.sax_1.0.0.r11210.jar I tried it again with the same result.
Your plugins seems fresh enough. When you try this, how quick is it? Is there any significant delay before you get the prompt back? What's the content of the .metadata/.plugins/org.eclipse.pde.core/.bundle.pool/ ?
It takes almost no time, a second or so. Here is what the workspace contains: kup@ubuntu:~/bz$ find ws4 ws4 ws4/.metadata ws4/.metadata/.plugins ws4/.metadata/.plugins/org.eclipse.jdt.core ws4/.metadata/.plugins/org.eclipse.jdt.core/nonChainingJarsCache ws4/.metadata/.plugins/org.eclipse.jdt.core/variablesAndContainers.dat ws4/.metadata/.plugins/org.eclipse.debug.core ws4/.metadata/.plugins/org.eclipse.core.runtime ws4/.metadata/.plugins/org.eclipse.core.runtime/.settings ws4/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.core.resources.prefs ws4/.metadata/.plugins/org.eclipse.pde.core ws4/.metadata/.plugins/org.eclipse.pde.core/.cache ws4/.metadata/.plugins/org.eclipse.pde.core/.cache/clean-cache.properties ws4/.metadata/.plugins/org.eclipse.pde.core/.local_targets ws4/.metadata/.plugins/org.eclipse.pde.core/.local_targets/1279612682842.target ws4/.metadata/.plugins/org.eclipse.core.resources ws4/.metadata/.plugins/org.eclipse.core.resources/.safetable ws4/.metadata/.plugins/org.eclipse.core.resources/.safetable/org.eclipse.core.resources ws4/.metadata/.plugins/org.eclipse.core.resources/.root ws4/.metadata/.plugins/org.eclipse.core.resources/.root/.indexes ws4/.metadata/.plugins/org.eclipse.core.resources/.root/.indexes/history.version ws4/.metadata/.plugins/org.eclipse.core.resources/.root/.indexes/properties.version ws4/.metadata/.plugins/org.eclipse.core.resources/.root/2.tree ws4/.metadata/.plugins/org.eclipse.core.resources/.history ws4/.metadata/.log
Just to clarify. The sample target definition that you attach is actually OK. It contains no errors. The title states that errors are silently ignored. If I alter the target definition so that it contains a bogus repository URL, then I get the same behavior as you do. In a way, that's normal since no attempt is made to actually resolve the target. But I assume that you use a target definition that is OK and that you still get this behavior. Is that a correct assumption?
I'm using the attached target definition (I downloaded it from this bugzilla for my latest tests). My main problem is really the "silent" stuff. It can easily happen that I make a typo in an URL and then it's virtually not possibly to find the reason when there is no message.
I added some sanity checking of the imported target. It will catch misspelled URL's, IU id's etc. The fix was released to helios-maintenance, rev 11509.
Thanks Thomas! I can confirm that it works for me with rev 11509. Just to be sure I also tried with the previous version of yesterday where the problem (no plugins downloaded) is still reproducible.
