Community
Participate
Working Groups
The PlatformConfiguration APIs only supports the modification of the currently running eclipse. This is a pretty annoying limitation when trying to configure other installations. I will attach some code that allow to remove this limitation.
Created attachment 41511 [details] Archive containing files modified to solve the mentionned problem The base used for this code is what went in eclipse 3.2. The core of the modification is done in the following classes: Configuration configurationParser FeatureEntry PlatformConfiguration PlatformConfigurationFactory SiteEntry The other modifications are mostly caused by package change and import reorg.
Created attachment 46844 [details] Patch to use absolute paths for site url in platform.xml Absolute URLs are needed for the URL attribute in platform.xml to configure other eclipse installations that have their features/plugins in a location different from the configuration.
Created attachment 48048 [details] patch Here is a patch based on the current state of the 3.2 maintenance branch. It combines code changes from both of the above attachments.
Created attachment 48651 [details] Smaller patch created by removing code changes that were not relevant to the fix. Created a smaller patch for org.eclipse.update.configurator containing Pascal's changes minus his reorg changes and one other change by me required to get relative site URLs configured correctly from other eclipse instances.
Can somebody package this as a patch plugin fragment for update manager? Thanks.
it doesn't seem that this is needed in 3.2.1. Is someone desperate for it?
Our product is going to be based on 3.2.1 and we desperately need it. We have been facing numerous problems related to the PlatformConfiguration getting wrong paths when trying to resolve relative site URLs from platform.xml and this patch will solve that for us. I had been in touch with DJ regarding getting the patch into 3.2.1.
As per Wassim request, I do (I mean I endorse).
See bug 156760 for the work-around released to 3.2.1.
Unfortunately, this can no longer be cleanly applied against the current configurator. Over to the runtime team.
Created attachment 72433 [details] ConfigurationActivator without most start/stop processing We removed the code that reconciles the installed bundles from the activator as this does not make sense in a copy of this code. Also removed some stop processing.
Henrich, do you have a clean patch against HEAD currently for this?
It would be absolutely amazing if this could be fixed some time in 3.4. Pretty please! :)
Hey Update guys, how about doing one for the "good old times" :)
I am waiting for the dust to settle and a working patch to emerge. I am unclear if the new patch applies against the code in HEAD.
Any update on this bug? If this were fixed it would prove to be immensely helpful to many developers currently developing with PDE. PDE works well in for self hosting, but it starts falling apart when someone tries to work on a target platform that contains a platform.xml. This could solve an age old problem for many developers.
I am going to repeat my question from the comment 15: is the last patch good to go and applies cleanly to the HEAD stream? We have no cycles to really test it, so be careful what you ask for :-). I can only yank it if it starts causing regressions.
The patch I added in comment 11 does not apply to HEAD. It is not ready for picking up.
Created attachment 81298 [details] Updated patch against HEAD (3.4) Integrated the existing patch with the current HEAD stream.
I have integrated the changes supplied in Attachment #48651 [details] with the latest code in HEAD. I did not add the new constructor PlatformConfiguration(URL url, URL installLocation) to the PlatformConfigurationFactory since this would introduce new API. The problem is that update still assumes the configuration directory is relative to the installation directory. In my usage, this is not the case. Not sure how to solve that without enhancing the API or using another system property to override the install location.
Pierre, nothing wrong with new API in the 3.4 timeframe. Dejan, Update is calling you.
(In reply to comment #21) > Pierre, nothing wrong with new API in the 3.4 timeframe. > Dejan, Update is calling you. Chris, according to comment #20, the new API has not been added. Are you still sure you want me to release the latest patch or you want me to wait until the API has been added?
Created attachment 82332 [details] Updated patch against HEAD (3.4) - with API changes Patch for changes against HEAD. Includes the API changes.
Released into HEAD.
