Community
Participate
Working Groups
Build ID: I20070625-1500 Steps To Reproduce: 1. Use a separate update site to keep some plugins 2. Launch an eclipse application 3. Check Preferences -> Plug-in development -> Target platform You can observe that the update site does not appear in the list. More information: This is causing a problem with JET2 when creating custom tag libraries. I installed the additional plugins in a separate directory. After creating a custom tag library it can be used only from a launched instance. Since PDE does not add the additional directory to the Target platform, the tag library and jet plugins can't be seen. Workaround: In the launched instance adding the additional directory and the workspace will solve the problem.
Just to make sure I understand this correctly, you are saying the the target platform from your host (the Eclipse instance you start from the command line), has additional information in its target platform. And when your runtime workbench is launched, its target platform does not contain this additional information, right?
(In reply to comment #1) Yes. This information is populated by eclipse itself because while installing additional packages I selected a different directory.
Are you self-hosting (ie. set your target platform to the same instance of Eclipse you are running with)? If so, what we should probably be doing is copying and modifying the platform.xml from the target platform instead of creating a new one from scratch. This should pass the additional updates sites to the new launched instance of Eclipse.
(In reply to comment #3) > Are you self-hosting (ie. set your target platform to the same instance of > Eclipse you are running with)? > Yes. > If so, what we should probably be doing is copying and modifying the > platform.xml from the target platform instead of creating a new one from > scratch. This should pass the additional updates sites to the new launched > instance of Eclipse. > I think this is the solution.
Care to tag it for bug-day. Would like to sign-up.
picking a tough one ;)?
(In reply to comment #6) > picking a tough one ;)? Hmm... then I will come around asking for help. Be around on IRC ;-).
The solution seems to be removing the isDevMode() check from PluginPathFinder#getPluginPaths() function. When this check is removed, the plugin view and target platform shows all the plugins including the workspace plugins. It looks right. There is a problem in the following scenario: Eclipse (0) -> Launched an eclipse instance (1) -> Launched eclipse instance (2) In instance (2), the workspace plugins from (0) are not visible because the classpath from (1) derived from dev.properties is not passed across. The solution is to merge the dev.properties. My guess is that the fix should go into ClassPathHelper. How does this sound? Any suggestions? I still did not go through it thoroughly. Since there is a TZ difference, I though I will do some analysis and get feedback. -- KD
I have to say it is funny how you learn about something that has been around for year, then amazingly you need that information multiple times in the next few weeks :) To make a long story short, we can't remove it :) If you want to know why, continue reading... The function isDevMode() is actually very important. The reason is some shortcuts PDE uses. The runtime allows you to run a project as a bundle, without exporting it. This is done by passing some extra information about where to load classes from (since class, by default, are in /bin instead of the root of the project). By doing this, the runtime is able to run these workspace projects correctly. But, if you try to launch a runtime workbench from your 1st runtime workbench, the second workbench is not passed the same information. Therefore, the second runtime workbench treats it as a regular bundle and when trying to load classes, you will get a bunch of NoClassFound problems. So to prevent this, we have the check for isDevMode(). This prevents your runtime workbench from including workspace plug-ins in its target platform and in any runtime workbenches.
Is this the only reason for this check? In that case, by merging the dev.properties from a workbench while launching another we can successfully pass the classpath. Anyhow, I will try to do this. (This is what I tried to communicate, rather unsuccessfully it seems :). I am also trying to use fullpath names in dev.properties so that the merge will be trivial. Meanwhile, if there are any other reasons for that check, please post them. Thanks.
This is what I tried till now: 1. Created a helper class to convert the dev.properties (if given) to full path names. 2. Merging these when a new dev.properties is created in ClassPathHelper. I checked the created dev.properties and they seem to be fine. 3. Removed the isDevMode() check. This ensures that the paths for the workspace plugins are propogated to the launched instances. Theoritically, that is ;-). I still get the CNF errors in the first instance of eclipse itself. I am lost at this time. Will try some more a little later. Why do we get CNF errors in the first instance itself. Does the entries in dev.properties used for resolving bundles in a plugin project? Any suggestions? -- KD
Atlast it works. But the approach is ugly. Need suggestions on how to implement this. Not uploading the patch because it is not good enough :( This is what I tried till now: 1. Created a helper class to convert the dev.properties (if given) to full path names. 2. Merging these when a new dev.properties is created in ClassPathHelper. I checked the created dev.properties and they seem to be fine. 3. Removed the isDevMode() check. 4. Checking for plugins passed through dev.properties in PDEClassPathContainer#addExternalPlugin. If it is passed from a host-eclipse instance the paths from dev.properties are added to the class path entries. What is bad: JDT does not allow external folders to be added to the class path. The workaround is to create a link IFolder#createLink. But IFolder#createLink can't be called outside a IProject. So we can't use preferences area to create these links. Two options are open: 1. Create a hidden folder in each of the projects and create the links there for the dependent plugins there. 2. Create a top level project for just keeping the link folders. I used (2) for trying this out. And it seems to be working. Any suggestions on how we can approach this? -- KD PS: Sorry that I could not finish it for the bugday. I will try to clean it up over the weekend.
Created attachment 77557 [details] Patch against CVS Head Hi, This patch contains fixes for this bug. I tried it against my original usecase of JET2. The following modifications have been done: 1. Guest eclipse instances have access to all the plugins defined in the host plugin. This includes the plugins in the host eclipse in source form. 2. If a host eclipse instance itself is a guest instance, the dev.properties are propagated across to its guests. 3. If a guest eclipse instance creates a plugin project that depends on a plugin from the host workspace, a linked folder is created in '__host__plugins' project. The __host__plugins and the links are created lazily when they are needed. This is needed as a workaround because JDT does not support adding external folders to classpath of a java project. This is a generic fix that works for any folders passed through -dev argument. Hope this is acceptable. -- KD
Did any of you look at this?
This problem should finally be fixed with bug 109137. *** This bug has been marked as a duplicate of bug 109137 ***
