Community
Participate
Working Groups
Build F3 I have PDE set up to use an alternative target platform (i.e. not the runtime platform). When i Update Classpath for my project, PDE tries to guess where the source for the plugins is. It creates variables like _ORG_ECLIPSE_PLATFORM_SOURCE. When it creates these variables, it points them at the runtime platform, not the target platform! This is very bad, since my runtime and target platforms are different versions of Eclipse, so the .class files and the .java files do not match each other.
I thought that I could fix these variables manually, but it seems like the PDE resets them periodically. This means that the only workaround I have is to actually copy the source ZIPs from the target platform into my runtime platform's plugin structure.
Everything is working as designed. What you need to do is: 1) Disable entries registered by the design-time Eclipse (uncheck them) 2) Add entries you want to be picked up Number 2) may be a problem if the runtime platform does not use the new source location mechanism, but this is how source will be delivered in 2.0. Reseting is strange - PDE is preserving the state unless you start with a new workspace.
I tried unchecking the _ORG_ECLIPSE_* entries on the 'Source Code Locations' page (I hadn't noticed this page before). I then added equivalent WSADIE_ORG_ECLIPSE_* entries for the real source code locations. When I Update Classpaths now, it seems to find the source code in the right place. But shouldn't the built-in variables be relative to ECLIPSE_HOME, rather than hard coded to my eclipse install? Hoping that I could save the rest of my team from having to do this, I exported my preferences. But on inpecting the preferences file, I could find no reference to my new variables. I also couldn't find any way to edit the variables on the 'Source Code Locations' page.
*** Bug 22617 has been marked as a duplicate of this bug. ***
Fixed. The default behavior now is that we point to the source code locations in the target platform, not the design-time platform. So you should be able to use different versions of Eclipse for design time/runtime and import source without any problems. As for the exporting preferences problem, that problem was fixed a while back.
Was this fixed for 2.0.2 stream or 2.1 stream? Thanks.
The 2.1 stream.
I still don't have source attachments (20021022). Looking at the PDE->Source Code Location, there are no entries at all. I could add new one, but I have no idea which name should be defined. What I still don't understand; I asked this in the duplicated bug 22617: Does the 'Source location' preference really has to do something with plugin importing? If it does, why is this setting on a preference page and not on the importer wizard page?
Martin, if there are no entries on the 'Source Code Locations' page, that means that in whatever target platform you chose, there is no packaged source. i.e. PDE could not find any plug-ins containing extensions to the ext pt. 'org.eclipse.pde.core.source' in the target platform. That is why no source could be located for the plugins you chose. If there is source and the zip files containing the source are named according to 2.0 convention, and whoever packaged the plugins just forgot to declare the extension needed by PDE, you can manually add an entry to the 'Source Code Locations' page. The name is not important, as long as it is unique, as long as it does not conflict with the name of an existing Java classpath variable (but PDE takes care of that anyways). What is important is the absolute path that you specify. To answer your question: the entries on the 'Source code locations' page have everything to do with importing source. As for why they are set on their own preference page, and not in the 'import' wizard, this is because source code locations' use is beyond just the import wizard. We use them when we update classpaths, when people import using the plugins view, when people use the import wizard, etc. Therefore, the values for source code locations have to be part of pde.core, not pde.ui. And their values are persisted along with other pde.core preferences.
I discussed the problems I'm having on private mail: This is the concludion: Wassim wrote: Now I see what might be the problem. In PDE language, when we refer to setting the 'Target Platform', it means setting it on the 'Target Platform' preference page. So by default, PDE looks up and sets the source code locations found in whatever platform you chose on the 'Target Platform' preference page. If, on the first page of the import wizard, you choose a location other than the target platform specified on the 'Target Platform' preference page, you have to manually add these source code locations to the Source Code Locations preference page, prior to the import operation for everything to work fine. An enhancement to the Import Wizard might be to inform the user to add the source code locations manually if one selects to import from a platform other than the Target Platform. There is also an enhancement bug open that suggests we should ask the user if he wants PDE to automatically change the value for the target platform if he chooses a different location in the import wizard. The current behavior is now keeping about 90% of people happy, and we are working on enhancements that will please the other 10% without upsetting the other 90. It's a delicate balance and we're trying our best.
