Community
Participate
Working Groups
The platform configuration has issues when working with other config locations. An example is running a host Eclipse instance (say 3.3RC1) and then loading a config of a target location (3.3M7). What happens is that the code around the configuration makes a lot of assumptions when dealing with 'platform:/' type URLs. It always queries for the current configuration which always happens to be the one of the host, and not the target. This causes bundles not to be properly resolved for clients of this class like PDE. The solution here is ensuring the resolvedURL of site entries is the URL of whatever platform configuration we are truly interested in, not the "current" one. From the PDE point of view, this blocks a fairly major bug in my opinion. We have done thorough testing on our end to make sure this change doesn't have any negative impact.
Created attachment 68433 [details] org.eclipse.update.configurator.patch Here is a patch that solves the problem.
Chris, this patch is 'The Blair Witch Project' scary. It modifies some of the most sensitive classes known to (Update) men. How certain you are that we are not going to break many of the Update scenarios this late in the cycle? Did you rerun the Update JUnit tests? DJ, Pascal, do you see what I see?
I agree with Dejan. We don't like changes in the update.configurator. And generally code which looks like this: File root = file.getParentFile().getParentFile().getParentFile(); I find a bit scary...
Upon further examination, all other changes seem reasonable exept that section: - URL rURL = PlatformConfiguration.resolvePlatformURL(pURL); - String resolvedURL = rURL.toExternalForm(); + File file = new File(this.url.getFile()); + File root = file.getParentFile().getParentFile().getParentFile(); + String resolvedURL = root.toURL().toExternalForm();
The line that Dejan points out in comment 4 needs an explanation certainly. However, I don't think a general 'We don't like changes to update.configurator' attitude is helpful here. This problem needs to be fixed either now, or in 3.3.1 (when the "happiness" hits the fan), as it poses a big problem for PDE, now that it supports multiple version of the same plug-in.
Wassim, are the code paths in this patch hit only during self-hosting or during regular Update use as well? My concern is mostly around Update scenarios being broken after this.
I am not sure as I did not write the patch. I do prefer if we have a solution that resulted in code only be executed by the PDE path. Unfortunately, Chris is not available at this time to comment.
I am in favor of ensuring that this problem is fixed in 3.3. However, I would like to see more assurance that we can isolate any potential regression to the PDE scenario only and do some more testing.
Is this bug a duplicate of 156760, bug 141887 or bug 102190? All 4 of these bugs seem the same.
(In reply to comment #2) > lol Dejan, I thought it was just "Texas Chainsaw Massacre" scary :) As DJ pointed out, this possibly looks like a dupe to the other bugs. DJ has an interesting patch in bug 141887, however, it looks "Hostel" scary :) DJ, was this a complete solution to the problem. Is it worth to investigate this for 3.3 inclusion, it's a fairly serious issue. After talking to Wassim, I'm going to try to make a patch PDE is only interested and as less disruptive as possible. DJs patch in bug 156760 may help that.
The patch for bug #156760 has been applied in 3.2.1 and it allows for the platform.xml to be properly read since PDE can now discover features mentioned in platform.xml, which means that somewhere the IPlatformConfiguration object has been created. Therefore I don't understand how an additional fix in update configurator will help solving bug #124539 since in the PluginPathFinder or pde.core you already get the PlatformConfig object.
Created attachment 69834 [details] org.eclipse.update.configurator.patch updated patch to be more careful about things and only include a PDE path. In PDE, we feel this is safe for a major problem in PDE.
oh btw Dejan, I hear you're a big fan of the phrase, "here is your damn patch"
(In reply to comment #11) Update configurator is still broken in regards to if you're working in self-hosting mode.
comment 13 was in honor of Mik
(In reply to comment #13) > oh btw Dejan, I hear you're a big fan of the phrase, "here is your damn patch" The full phrase must be preceeded with a few whiney 'Where is my patch, where is my patch', to which you add the zinger from above :-).
Scheduling for RC4, reviewers to follow.
Dejan, don't forget this one :)
In PDE, we never forget ;)
OK, at this point we have one component lead vote (Wassim) - soliciting two peer committer votes (John and Pascal). The final incarnation of the patch makes me feel better because it is clear that these paths are less traveled (for a reason :-) - only when invoked by PDE.
I don't think I'm the right person to review this patch. I know almost nothing about update configurator, so I can't gauge the risk/reward of this fix. My gut says to defer this to 3.3.1 - we're a couple of days from the final planned 3.3 build, which leaves zero margin of error if this fix isn't perfect. Maybe DJ will give you a +1.
This fix is part of a larger bug fix in PDE for which the PDE team feels very strongly, otherwise I would defer myself.
Could an answer be given to the question in comment #11?
Pascal, I think it has been in the comment 14. I think that it fails to cover the self-hosting scenario (when Eclipse is launched by PDE as opposed to using the standard launcher).
As a stupid test, I have compiled update configurator and installed it on top of a brand new I20070605-0010 and I can't start eclipse. This is an obvious -1.
Agreed.
Since there are issues still, will target to 3.3.1 and investigate remaining issues.
As you are preparing the patch, DJ and I strongly encourage you to look at the patches from the bugs mentioned in comment #9.
OK, one less to worry about. See, when I get scared it is not without reason :-).
I just wanted to follow up and see if getting this patch into 3.3.1 is still in the cards.
Apparently not - the original concerns were not yet addressed (see above).
We were able to fix the patch to work in that specific case. But this fix seems to be more of a band aid to fix a deep cut. Instead, we would like to see if we can get bug 141887 fixed (equivalent to stitches). The bugs this would fix for PDE in 3.3.1 are not must fix. Therefore, Chris and I both agree it would be best to fix this once and for all the right way in 3.4 instead of applying this patch to fix certain cases. It is our hope we can go back and clean up the 141887 patch since we are still very early in the 3.4 development cycle. I will also need go to out and rent "Hostile" so I can understand just how scary the patch is :)
Given that bug 141887 is now marked fixed, can this bug be closed?
In the absence of further comments from the reporters, I guess the answer is yes. Closing as WONTFIX since 141877 was the bug that was actually fixed.
