Community
Participate
Working Groups
I'm trying to install a Buckminster headless configuration using the director application from 3.6. This is the command I'm using: eclipse -application org.eclipse.equinox.p2.director -nosplash -i org.eclipse.buckminster.cmdline.product -r http://download.eclipse.org/tools/buckminster/headless-3.6 -p Buckminster -d /home/thhal/tmp/buckminster-bad This resulting install is not runnable. The config.ini is huge and the osgi.bundle propery lists all bundles. The setting for eclipse.application is not present. If I instead use director based on 3.5.2 to install the same IU from the same repository, the result is quite different. The osgi.bundle property only lists the equinox.ds and equinox.simple.configurator bundles and the eclipse.application property is present. The application runs as expected. This install can be produced using the following commands: wget http://download.eclipse.org/tools/buckminster/products/director_latest.zip unzip director_latest.zip ./director/director -i org.eclipse.buckminster.cmdline.product -r http://download.eclipse.org/tools/buckminster/headless-3.6 -p Buckminster -d /home/thhal/tmp/buckminster-good This is currently blocking all buckminster users from using the new director. Any advice on how to work around the problem is greatly appreciated.
Created attachment 172849 [details] Broken config.ini from the 3.6 based install
Created attachment 172850 [details] OK config.ini file from the install using a 3.5.2 director
If anyone has an advice on where to look for what it is that's causing the radical changes in installs between 3.5 and 3.6, that would be greatly appreciated.
I tried installing the product org.eclipse.sdk.ide using the director. The install produces the same bogus config.ini so I'm raising the status on this bug to critical. I have tried to debug what's happening but I'm uncertain how it is supposed to work so I haven't been able to pinpoint the problem. I need help with this from someone who knows about the simpleconfigurator etc. The problem is easy to reproduce. Use an Eclipse 3.6 (the release) and issue the following command: eclipse -application org.eclipse.equinox.p2.director -nosplash -r http://download.eclipse.org/eclipse/updates/3.6 -i org.eclipse.sdk.ide -d <some absolute path>/eclipse -p SDKProfile Compare <some absolute path>/eclipse/configuration/config.ini to the config.ini from a classic distro.
I replied in mailing list, but I'll paste my comments here as well to keep it consistent. Briefly, when you're trying to persist your runtime changes, the infrastructure checks whether simpleConfigurator bundle is listed and started in config.ini osgi bundles. If that condition is satisfied, installed IUs will be persisted in bundles.info, if not - in config.ini (as it is in your case). In your config.ini simpleConfigurator is with start level 4 and is not marked to be started. I have some troubles opening the repository but would you check in the content.xml whether the IU "toolingwin32.win32.x86org.eclipse.equinox.simpleconfigurator" is presented? It is responsibe for setting start level 1 and mark the simple configurator bundle as started. But it is only applicable for win32x86 architecture - you have to define it in your profile (eclipse.p2.profile=Buckminster) as profile property. If your architecture differs from that, you will need corresponding IU for that architecture. I guess that is what lacks in your configuration and the issue will be solved when you update your profile with the property I mentioned.
I can't comment on the validity of the director call you are using, but the following works correctly with 3.6 (SDK install, simple config.ini): eclipse -application org.eclipse.equinox.p2.director -nosplash -consoleLog -flavor tooling -p2.os linux -p2.ws gtk -p2.arch x86 -roaming -profile SDKProfile -repository http://download.eclipse.org/eclipse/updates/3.6 -destination $(pwd)/temp.sdk -profileProperties org.eclipse.update.install.features=true -installIUs org.eclipse.sdk.ide PW
Katya, thanks for the elaborate explanation. It would help me a lot if you could take the time to answer a couple of more questions. I'm concerned that I'm unable to install the IDE from the platform repository using the director of 3.6 classic IDE. Is the IDE product itself lacking the needed configuration (see comment 4) ? The profile is created from scratch by the director. Why do I need to provide explicit properties for it? Is the directors defaults incorrect? Lastly, why does the product install without problems when I use an older director? I still install the same 3.6 IDE from the platform repository. Is this a regression?
> I'm concerned that I'm unable to install the IDE from the platform repository > using the director of 3.6 classic IDE. Is the IDE product itself lacking the > needed configuration (see comment 4) ? No, the product is fine - it describes what you will install. The repository is also fine because it contains all IUs you need to perform proper installation. What went wrong is the installation process which is unable to create proper plan for installation - p2.planner should attach (in your case) tooling for simple configurator bundle to the real bundle. The "tooling" is an advice what should be done with this IU - i.e should be started, should have start level 1. That tooling in particular has a filter which says it should be attached only to IUs "marked" for architecture win32x86. And the planner will attach that advice to any IU only if the IU matches that filter. To put a property in your profile is one way to make the planner attach those 2 bundles. There may be other ways to do this but I personally don't know how. > The profile is created from scratch by the director. Why do I need to provide > explicit properties for it? Is the directors defaults incorrect? I checked director application and it seems the defaults haven't been changed recently. I'm not sure what should be the defaults. But you are not right that the profile is create from scratch - from my experience there is a default profile that is already created when you install Eclipse IDE. And then when you perform any operation via the IDE, that profile is used as a baseline. Again, that's what I've seen during debugging creating of profiles. > > Lastly, why does the product install without problems when I use an older > director? I still install the same 3.6 IDE from the platform repository. Is > this a regression? Unfortunately one more question I cannot answer. Just guesses here - maybe the default profile had changed, maybe the properties that are passed to director app are inherited from somewhere (another configuration, workspace, etc). I'm not familiar with the environment the IDE apps run in.
(In reply to comment #8) > But you are not right that the profile is create from scratch - from my > experience there is a default profile that is already created when you install > Eclipse IDE. Not sure what you're saying here. I install the IDE product into a previously empty location. I'm certain that there's no profile. The directory is indeed empty and I'm not using any shared profiles. Do you mean a preconfigured default profile that the director adds to my product?
I verified that the director creates a good install if I provide the the following options on the command line: -p2.os=linux -p2.ws=gtk -p2.arch=x86_64 This is the same as my running platform which makes me suspect that in 3.5.2, these values used that as the default. I'm lowering the severity to normal since I'm now able to continue and can tell other users what the problem is. I don't want to close this bug since I consider the change a regression and an API breakage (it broke my builds for sure). Thanks again for all your help.
Changing title to match the actual problem. Note that the SDK metadata has all configuration information in platform specific CUs so won't work if no os/ws/arch is specific for the install. If Buckminster is intended to be platform independent, then there may be a metadata publishing problem if the configuration settings are not being made platform independent as well.
Created attachment 174819 [details] Patch to set defaults This patch uses the EnvironmentInfo service to set the defaults for os, ws, nl, and arch.
(In reply to comment #11) > If Buckminster is intended to be platform independent, then there may be a > metadata publishing problem if the configuration settings are not being made > platform independent as well. Buckminster itself is not platform independent but our bootstrapper, a minimal headless version of the director application, is. When building it, we create a p2 repo and install it from there using linux,gtk,x86. After that, all shared objects, the launcher executable, etc. are removed. Java Launchers for all platforms are added (hard coded in the build) and scripts (both sh and bat) are provided for the actual launch. It's not pretty, but it works. Ideally, I'd like to see a supported way to create a multi-platform director.
Andrew, can you please review my patch?
For headless and platform independent scenarios, there is no need to have those settings. As such I think it would be great if we could add a flag to disable the automatic use of these variables. Aside from this, I'm fine with the patch.
(In reply to comment #15) > For headless and platform independent scenarios, there is no need to have those > settings. As such I think it would be great if we could add a flag to disable > the automatic use of these variables. Aside from this, I'm fine with the patch. The current patch deals with a behavioral change from 3.5 to 3.6. The change breaks builds that doesn't provide the options. I think that an added option to avoid defaults is an enhancement that should be dealt with in a separate bugzilla. I added bug 323104 to cover that. I suggest that this patch is committed first and that we make a decision on how to proceed in the other bugzilla. Is that OK?
> I suggest that this patch is committed first and that we make a decision on how > to proceed in the other bugzilla. Is that OK? Patch released in HEAD and 3.6.x.
There was a problem with tagging HEAD so this fix won't appear in integration builds until the first build after 3.7 M2.
Did this patch not make it to 3.6.1 either? I seem to have the same problems there still.
The code is there in 3.6.1. If you have problems with it then please enter a new bug with details and reference this bug as well. Thanks.
