Community
Participate
Working Groups
The RCP framework emphasizes the ability to share INSTALL locations among different "applications". Each application can choose a subset of the features installed in the INSTALL locations. Currently, the only way to do this is to set the "/site/policy" attribute to "USER-INCLUDE" or "USER-EXCLUDE" in platform.xml and populate the "site/list" attribute with plugins. This is prohibitively complex. In particular, "USER-EXCLUDE" requires constant management to reflect the current list of plugins in the INSTALL location. It also requires that developers of "application" features have some knowledge of how eclipse has been installed on the client machine. Adding a "MANAGED-ONLY" setting to the "site/policy" attribute would simplify this process. Under "MANAGED-ONLY" mode, only those plugins referenced by features that are enabled features would be available to the application. This would be relatively easy for the framework to derive and would provide a straight forward way to select which plugins are available in an individual application.
This sounds like a good idea. In the past, for performance reasons, we've been thinking to actually list the plugins right under features inside platform.xml. The current approach with USER-EXCLUDE is usually very fast, because we just pick up all the plugins without having to parse the features.
Call me lazy, but I'd rather just keep the list of plugins associated with a feature in one place (feature.xml). Speaking for myself, I'd be willing to live with the one-time performance hit of letting the framework resolve all of this when faced with having to do it all at development time (especially since "org.eclipse.platform" is one of the required features). Maybe "plugin" could be an optional element under "feature" for people who have the stomach for that.
Changing component to match owner.
Like the idea, feature defs should be a controlling element, at least for those that want them to be... While we are at it, can we get some doc on the platform.xml syntax? (or pointers, I've searched but not yet found any). I'd like to understand transient="false" vs transient="true". I've fiddled and seem some differences in operation, but I'm not sure yet they are what I expect.
the "transient" flag (just like some of the update apis', and the USER-INCLUDE policy) have been defined specifically for PDE. When "true", it tells the update configurator to just use the platform.xml as is, and don't try to detect file system changes (i.e. don't check if new features/plugins have been installed/removed, etc.).
Hmm... maybe we should talk about what this is close to being - as it is something I get asked about fairly often. What I noticed what when I started Eclipse with -configuration e:\xxx that I'd get my own platform.xml file (and other standard config dir stuff). I also noticed that the contents of this file depended if/when I had started eclipse without a -configuration option - meaning if an existing config was there or not. When no existing config - my platform.xml looked something like this: ----------- <?xml version="1.0" encoding="UTF-8"?> <config date="Sat Apr 03 16:49:49 EST 2004" transient="false" version="3.0"> <site enabled="true" policy="USER-EXCLUDE" updateable="true" url="platform:/base/"> <feature application="org.eclipse.ui.ide.workbench" id="org.eclipse.platform" primary="true" url="features/org.eclipse.platform_3.0.0/" version="3.0.0"> <root>platform:/base/plugins/org.eclipse.platform_3.0.0/</root> </feature> <feature id="org.eclipse.platform.source" url="features/org.eclipse.platform.source_3.0.0/" version="3.0.0"/> <feature id="org.eclipse.jdt" url="features/org.eclipse.jdt_3.0.0/" version="3.0.0"/> <feature id="org.eclipse.jdt.source" url="features/org.eclipse.jdt.source_3.0.0/" version="3.0.0"/> <feature id="org.eclipse.pde" url="features/org.eclipse.pde_3.0.0/" version="3.0.0"/> <feature id="org.eclipse.sdk" url="features/org.eclipse.sdk_3.0.0/" version="3.0.0"/> </site> </config> ----------- And I could issue -command addSite transactions to adjust this private config if I included the -configuration option on the addSite transaction. I also noticed that I if I started eclipse with -configuration AFTER having started eclipse without -configuration (meaning a platform.xml existed in the default location) - then my private config platform.xml looked like this: ----------------- <?xml version="1.0" encoding="UTF-8"?> <config date="Sat Apr 03 16:58:15 EST 2004" shared_ur="file:e:/Eclipse-3.0/M8- Install-Testing/eclipse/configuration/platform.xml" transient="false" version="3.0"/> ----------------- When I changed it to transient="true" then I started to see things I liked. I have to rerun all my tests to be exactly sure, but I seemed very close to having a private config I could change (addSite or UI), but where the base was specified by the ref to the existing eclipse/configuration dir contents. Or- the goal: Shared install of Eclipse/Eclipse-based software. Base components in/out based decisions by owner of shared install. Users of share install get the common config 'forced' on them, but still have the right to add/remove additional software. That is the basic rqmt - options would include the right to disable/enable content from the shared config (should be a right granted by owner), or not use the shared config at all (not as important; workaround if you don't like shared config is to install your own copy). I think this is a scenario that comes up in product level discussion - and something that we are close to - so should consider trying to identify what will/won't work based on today's code and what it might take to get one or two of the shared install config management options functional and supported. I'm going to run my test scenario's again with current code and report what worked as-is vs with a platform.xml edit. I'll report my findings. I'd like to know if you consider this a worthwhile objective.
Pat, some details on shared config can also be found in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=49141#c4 (I think you're cc:ed on it). We have not yet made the platform.xml public, but I think we should. In addition to the transient attribute, drop the date attribute on the <config> element, as the it should be the timestamp of the file itself. Our code will read the platform.xml and resave it with the appropriate timestamp set. (the date and the transient attributes need a bit of a re-work). With the current code, features from the shared location cannot be updated/disabled as they are thought to be read/only. A right-based management is interesting, but I don't see this happening in 3.0. We have not had this kind of requirements, so we never planned for it. If you see this as something important, please gather the relevant data and let's discuss it for the follow up release. This should play nicely with the idea of update policy configuration that Peter M. and I have been discussing.
Dorian already knows this, but I'd just like to emphasize my team's support for the MANAGED-ONLY policy type idea. We are against the suggestion of listing the plugins under the feature in the platform.xml and in general do not like having to list excluded plugins in there right now (necessary to perform an 'upgrade'). We would rather take the one-time performance hit (which really should be small) of having the configuration's includes/excludes calculated by parsing the <site>'s <features>s and only including plugins that are explicitely included by features that are explicitely listed in the sites. I don't think I'm adding anything new to this thread other than to clarify our support for the enhancement request. :-)
The default site policy is USER_EXCLUDE. How do you expect the MANAGED_ONLY to be used? - product provider manually ships a platform.xml with the MANAGED-ONLY site policy set - a plugin preference key - other ideas ?
I checked in the code for supporting a MANAGED_ONLY site policy. The side effect is that the org.eclipse.update.configurator.IPlatformConfiguration.ISitePolicy received a new static filed MANAGED_ONLY=2, so this is an API change. However, this interface is not meant to be subclassed by users, which I think makes it a non- breakable change. In essence, you can create the eclipse/configuration/platform.xml and ship with the product. The platform.xml can be created manually, or using the update.configurator API's to create a configuration.
I am requesting this bug be reopened for 2 reasons. It is the easiest way to restart the discussion about MANAGED-ONLY and get the original contributors to this idea aware. Some of the ideas were not fully developed and need to be addressed in a future release. Since we are implementing a product based on MANAGED-ONLY we need to assure we are not going in a direction that will be inconsistent with future implementations. 1. Here is what I believe was agreed to previously by this bug. 1a. eclipse/configuration/platform.xml must be shipped with the product 1b. Only plugins specifically managed by features listed in platform.xml are used. This is based on comment #8 and is consistent with how the resolver code was written in the configurator. 2. Unresolved issue: Comment #9. The default site policy is USER_EXCLUDE. If all one wanted to do was ship a static platform.xml and never changed it then we would be done. However realistically this is not very useful. There still has to be the abilty to update features, add features etc. It would be best if this could be done using update. Bottom line is MANAGED-ONLY is very useful if you can use update functions and is only marginally useful if you can't. A mechanism needs to be included to change the default policy. I will open a new bug for this one as it needs to be in 3.2. I will also provide a patch. 3. Unresolved issue: Comment #9. How do you expect the MANAGED_ONLY to be used? First item #1a and item #1b are OK. The platform.xml can be modified though the use of the standard install, uninstall, enable, and disable commands/operations. It can even be updated though the use of update.ui if desired. This allows the configuration to be managed. The configurator should honor this and not modify the configuration EVER. The update operation/methods should also honor the specified policy and not change it. 4. Problems. 4a. Symbolic linked sites in links file do not fit with MANAGED-ONLY since there is no way to initially indicate features that should be enabled or disabed. 4b. The configurator will add in features that have a timestamp later than the platform.xml. For a multiuser scenario we should be able to install a feature into a shared site and selectively enable it for users. However the configurator using its reconciliation methods may decide to install into a user's configuration. Fortunately by using transient="true" both 4a and 4b can be avoided. 4c. Any change to platform.xml will cause it to be written out using the USER_EXCLUDE policy. As mentioned above I will open a bug for this behavior. 4d. Policy decisions are made outside of the policy. When only USER-EXCLUDE for implementations and USER-INCLUDE for the PDE that worked however it causes problems for MANAGED-ONLY. Solutions to the these problems should be included in the next release. If we don't think it is appropriate to reopen this bug then I will open a new bug.
Reopening so we can look at it later.
DJ, John, this is in update configurator. Where are we on this one?
If/When addressed: Please make sure to attach the 3.3 patch, and risk assesment for a 3.2.2 backport.
There is no patch for this bug. It was used as a placeholder. All patches have been attached to other bugs. Thanks.
Is this bug needed then? You should either close it or link it to other bugs that carry actual patches.
Is this bug covered by bug 167687 ?
Yes. Bug 167687 is the last of the managed-only changes.
Closing because bug 167687 and others cover this topic now.
