Bugzilla – Full Text Bug Listing
| Summary: | [p2] cannot compile against plugins referenced via .link files | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] PDE | Reporter: | Carsten Pfeiffer <carsten.pfeiffer> | ||||||||||
| Component: | UI | Assignee: | Curtis Windatt <curtis.windatt.public> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||||
| Severity: | critical | ||||||||||||
| Priority: | P3 | CC: | caniszczyk, darin.eclipse, dj.houghton, eclipse.sprigogin, ekke, john.arthorne, ob1.eclipse, sflaniga, simon_kaegi | ||||||||||
| Version: | 3.4 | ||||||||||||
| Target Milestone: | 3.4.1 | ||||||||||||
| Hardware: | PC | ||||||||||||
| OS: | All | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Carsten Pfeiffer
Sorry, this was supposed to go to PDE (I hope that's where it belongs to...) FWIW, it doesn't seem to work with the dropins/ folder either. I.e. I removed the entire links/ folder and copied the plugins and features (e.g. GEF) into dropins/. The plugin is indeed available: osgi> diag org.eclipse.gef reference:file:dropins/gef/plugins/org.eclipse.gef_3.4.0.v20080508.jar [150] No unresolved constraints. Still, the manifest.mf editor complains that "Bundle 'org.eclipse.gef' cannot be resolved". This bugs breaks many existing Eclipse installations and should be considered critical. Eclipse 3.4 (or at least p2) should not go out until it's fixed. Are you aware of the new target platform preference? http://mea-bloga.blogspot.com/2008/04/new-target-platform-preference.html The docs should be updated with this information too. Created attachment 104899 [details]
screen shot of target platform pref page
This works for me. I downloaded ECF from the Ganymede update site, and placed the plugins in "c:\temp\LinkLocation\eclipse\plugins". Then I added a "links\ecf.link" file with the contents "path=c:/temp/LinkLocation".
On restart, I went to the target platform page, and saw all the new ECF plug-ins available in the target platform, grouped by location. I have the preference to "build target platform based on the target's installed plug-ins" checked.
Then, when I check an ECF plug-in out of CVS that requires some other ECF plug-ins the build path (Plug-in Depedencies) are computed properly, and compiles without error. As well I can create a new plug-in with a dependency on any ECF plug-in. They appear in the dialog when adding required plug-ins. What I did notice is that when I delete the .link file/folder from my root install, p2 still thinks the linked plug-ins are part of my host IDE (and the bundles still appear in bundles.info). However, this feels like a separate p2 issue. Thanks for the tip with the target platform configuration. The problem is certainly related to that and the -configuration switch. When you start eclipse with the -configuration switch, neither the dropins, nor the links folder are automatically added to the target platform. Moving to runtime for comment - this is not a PDE issue if the -configuration switch is changing behvaior. Both "links" folder and "dropins" work for me with or without "-configuration" argument (Eclipse 3.4RC4). Possible points: - Where you pointing "-configuration" to? Is it a valid path? What happens if you point it to a new directory? - Can you try with Eclipse 3.4 RC4 - or better yet with one of the last I-builds as few problems have been fixed for RC4 I'm also using RC4 by now (problem remains). And I copy the pristine configuration directory from eclipse to a new location and point to it with -configuration. Here's how to reproduce this (on Linux): The emf_uml2 folder contains emf and uml2 features+plugins. ~$ mkdir /tmp/et ~$ cd /tmp/et /tmp/et$ tar xfz ~/eclipse/eclipse-SDK-3.4RC4-linux-gtk.tar.gz tmp/et$ cd eclipse/ /tmp/et/eclipse$ cp -r ~/eclipse/emf_uml2/ dropins/ /tmp/et/eclipse$ cp -r configuration/ /tmp/ /tmp/et/eclipse$ ./eclipse -data /tmp/wstemp -configuration /tmp/configuration Now open the Target Platform preference page, check "Group plug-ins by location" and you will notice that the emf_uml2 folder is not shown, nor are the emf2/uml2 plugins. Here is my setup: (done on Linux) - take latest build and extract it to /home/dj/eclipse - mv /home/dj/eclipse/configuration to /home/dj/configuration - cp releng.tools bundle to /home/dj/eclipse/dropins - start eclipse with -console and -configuration /home/dj/configuration Here are my findings: - the Releng Tools bundle is installed in the system. (do an "ss" in the OSGi console) - the Releng Tools bundle appears in Help -> About -> Plug-in Details - the Releng Tools bundle DOES NOT appear in the Target Platform preference page (whether or not it is grouped by location) - the Releng Tools bundle IS NOT available if I create a new bundle and try to add a dependency on it in the manifest. When I set the same thing up but use the default configuration location, the Releng Tools bundle is available in all cases. Darin, how does PDE populate the Target Platform preference page? (In reply to comment #12) > Darin, how does PDE populate the Target Platform preference page? If the "Build target platform based on the target's installed plug-ins" box is checked, we parse bundles.info. Else we scan the plug-ins directory for bundles. *My tests were done on XP, without changing the configuration location* Back to PDE. We looks for the configuration area in the eclipse home folder, which does not work in this case. Problem is in P2Utils.getConfigurationArea(...). Should fix for 3.4.1. DJ, how does one programmtically obtain the "configuration location" specified by "-configuration"? By acquiring an OSGi service, of course! :-) The service is called Location and you use a config location filter. We have some examples in our code. Check out the org.eclipse.equinox.p2.reconciler.dropins bundle. In the Activator, for instance, we grab the config location. Also note that config locations can have parents/be cascaded. (for instance in the case of shared install) Or use Platform.getConfigurationLocation() *** Bug 238950 has been marked as a duplicate of this bug. *** Created attachment 107012 [details]
Fix
Changes P2Utils to use Platform.getConfigurationLocation().
DJ, you mentioned that the location could be cascaded/have parents. Could you explain how this might affect the code? In this patch, we are getting the location, getting a URL, and then appending the path to the specific file (bundles.info/srcbundles.info).
This needs some more testing to make sure we aren't causing any regression, including the area of target weaving (there were issues about getting the configuration area different when in dev mode).
Created attachment 107013 [details]
mylyn/context/zip
For instance when you install Eclipse to a read-only location, the configuration is cascaded... you will have a local configuration area in your user dir and then it will have a parent location in the read-only area. See Location#getParentLocation. Adding Simon to the CC list as he knows more about the shared configuration scenario. What did we decide about the bundles.info file in the cascaded case? Are they merged or does the user copy contain everything? As far as I know, PDE has never supported the cascaded case properly so that would be more of an enhancement. I'm testing out the patch in various scenarios. Created attachment 107084 [details]
Updated Fix
This patch catches an additional case, when you have a target platform pointed at a non-default location and have you are trying to build the target platform from only installed bundles (check box is checked). In this case we just try platformHome/configuration and see if it works.
Fixed in HEAD and 3.4.1 just wanted to confirm, that fixing this bug also fixes my bug 238950 (resolved as duplicate of this bug) thanks ekke |