Community
Participate
Working Groups
I have taken a generic OSGI bundle (eSWT to be exact), created a directory in the eclipse runtime ("/eclipse/plugins/com.ibm.eswt", unziped the OSGI jar bundle in this directory. The META-INF/MANIFEST.MF file contains the line "Bundle-ClassPath: .". When building a custom plugin that requires eSWT, the PDE reports problems that it can not resolve anything from the OSGI bundle. If I copy the OSGI bundle jar file into the runtime plugin directory ("/eclipse/ plugins/com.ibm.eswt"), extract the MANIFEST.MF file that contains the line "Bundle-ClassPath: eSWT.jar", PDE will build everything correctly. I've been imfored that "Bundle-ClassPath: ." should also work. This problem is seen the in the M9 release.
So if I'm correct you are modifying your eclipse install isn't? Do you see this plugin in your target platform?
In PDE you are allowed to create a plugin that has a runtime library of ".". This translates into having "Bundle-ClassPath: ." in the bundle manifest file for the plugin. When developing this plugin in your workspace the plugin works great. It can be included in a runtime workbench. Other plugins in your workspace can depend on this plugin in your workspace and all the classes that this plugin exports are resolved by the bundles that depend on it. You can also export this plugin as a deployable plugin or fragment. If you take the result of the export and extract it onto a brand new install of eclipse then the runtime will pick up the plugin and install it into your working eclipse. But if you then bring up PDE and create a new plugin and make it depend on the plugin that you deployed into eclipse then PDE will fail to setup the correct classpath to include the bundle that has "." as its runtime library. I think this is working when the plugin is in the workspace because of the dev classpaths that are setup for plugins from a workspace. But if the plugin is actually deployed the dev directories do not exist and I think PDE is not interpreting "." correctly to mean that the bundle itself is the runtime library for the bundle. This is really just a development time issue. I think the deployed bundle is getting installed and working on the runtime workbench as long as it is not a jar'ed bundle see bug 58658.
I will attach a zip with two projects and a zip with a deployable plugin to demostrate the problem. Here are the steps to reproduce: 1. Extract the zip with the two sample projects. This zip contains two projects org.eclipse.dottest // bundle with Bundle-ClassPath: . org.eclipse.requiredot // bundle that requires org.eclipse.dottest 2. Import the two projects into a workspace. From this workspace you will see that both project compile and can be launched into a runtime workbench and can be started from a the osgi console in the runtime workbench. 3. In another "fresh" eclipse install extract the zip with the deployable org.eclipse.dottest plugin. And start eclipse with a clean workspace. 4. Import only the org.eclipse.requiredot project into the workspace. You will see that it cannot compile because a class imported from org.eclipose.dottest cannot be resolved. But the plugin dependencies got resolved and correctly show that the deployed plugin should be on the classpath.
Created attachment 11297 [details] two projects that demostrate the problem
Created attachment 11298 [details] deployable plugin that demostrates the problem
Following your steps I can not reproduce with I 20040529-0105. Could you please confirm it is the case for you too.
Never mind. I got it reproduced. I thought it was a PDE Build problem, therefore I only looked to see if I could export things properly once imported in the setup you described. However I've just found the problem. It is in PDE-UI.
PDE certainly adds the external class folder to the classpath. You could verify this by expanding the Plug-in Dependencies container on the Libraries tab of the Java build path property page of the project. However, it seems that JDT/Core does not recognize it. The project's code does not compile against it, and the types found in that class folder are not added to the Java search, i.e. if you do an Open type..., the list will not contain DottestPlugin or ExportClass that are both coming from the external class folder.
Moving to JDT/Core.
This is dependent on external class folders. However, the specification does not allow these (See comment on javaCore.newLibraryEntry: (partially extracted here: The target root folder can only be defined internally to the workspace (absolute path relative to the workspace root). To use a binary folder external to the workspace, it must first be linked (see IFolder#createLink (...)). The error message in this case is unclear (I needed to deduce this).
Since there seems to be a way for this, I'm moving it back to PDE/UI. cc Philippe just in case. What I didn't understand either though is if you import one of the test plugins that Tom provided into the workspace and you do an Open Type. They types declared in them do not show up in the selection dialog.
As John described earlier, external class folders are forbidden. We will simply ignore them from thereon, when compiling, searching, etc.... We only tolerate external archives to be used (external .class files would be to difficult to deal with without having any notification when they change; once an external folder is mounted, then it will be monitored by platform, and thus eligible on a classpath).
It might be interesting to relax this a little. Rather than saying it is not allowed because something could go wrong, allow external dirs and word the API etc such that clients clearly know the risks and can either take steps to avoid the issues (e.g., notifying you of changes or warning users of dangers). We are between a rock and a hard place here. On the one hand PDE is unable to tool plugins in jars so our workaround is to unzip the jars. But then JDT is unable to see the code because it is not in a jar. Wassim, is the PDE workaround to do something analogous to the external plugins project and rather than linking in the code jars from the external plugins link in the external class folders (i.e., the external plugins dirs)?
The External Plugins project, as it is currently implemented, is actually quite orthodox, as far as JDT is concerned. It is a simply a project with a JRE container and a PDE container, where the JRE container resolves to the default JRE and the PDE container resolves to project references to all plug- in projects in the workspace and all the JARs found in external plug-ins. Here is a simple example of how I picture this scenario working in 3.0, given all the limitations and the lack of options left as observed in comment #13. 1. We have a plug-in X in a JAR. PDE does not support this format, so we require for users to blow it up into a directory in the plugins directory. This will make it look like any traditional plug-in, and hence PDE will recognize it. At this point, the code for plugin X is now at the root of plug-in X's directory on disk, and the Bundle-Classpath header for said plugin is equal to '.'. This is all fine. 2. Now suppose we create a plug-in A in the workspace using the new plug-in project wizard. Its classpath contains the PDE container. If we go to the dependencies page of the manifest editor, and click on Add. The dialog that will show up will include plugin X - All good. So we add it, and we save. This triggers the recomputation of plugin A's container, which must now include code from plugin X. 3. During the computation of plugin A's classpath, when we get to the X plugin, we ask it for its libraries and we get '.'. By default, we typically append the name of the JAR to the installation directory of the plugin and make sure that the file (or directory) that it maps to actually exists. In this case, it will of course exist. So far, no changes in PDE's classpath computation. All good. Here is what we need to do differently, we should the file that corresponded to the library of plugin X to see if it is a file (i.e. JAR) or a directory. If it's a file, then it's business as usual for PDE. If it's a directory, then we create a linked folder on plugin A that maps to the install location of plugin X.
Re: comment#13. There is no issue really here. Functionality wise, you can mount any external folder as a resource folder, and from thereon reference it on a build path. PDE did not follow our spec, and I admit we did not issue a decent error message in this scenario. Your thought about a simple unsafe but tolerable mode is interesting, but far from the reality we observe. Clients want both flexibility and reliability. External JARs are already hairy to manage; and their support was added before platform allowed to mount external resources. Re: comment#14: I don't see "all the limitations and the lack of options"; but rather the fact PDE wasn't aware of the proper way to handle external folder. If you still believe there are, then please log a separate feature request against JDT Core; but as I said external class folders are a no go; unless we want to duplicate the platform support for managing resources, issuing deltas etc... so that all tooling will react properly (think incremental build etc...).
When I said "all the limitations and the lack of options" in comment #14, I was actually referring to PDE not being able to support the plugin in JAR format at this stage in the 3.0 cycle. Nothing more.
I explicitly created a linked folder for dottest and added this to the classpath. With this change, I can start requireddot and do searches, etc. So Wassim's proposal (comment 14) should work.
ok, we have a problem. I am unable to create a linked folder during the resolution of the pde container because the resource tree is locked for modification by JDT/Core.
JDTCore never locks the resource tree for modification. Isn't it rather that your attempt is occurring during POST_CHANGE notification where resource tree is locked ?
Since the resource tree is locked at the time of the container resolution, I am not sure how to proceed from here.
Where are you trying to create the link? Is it reasonable to create the link in the External Plugin Libraries project at the same time you do it for the jars?
If we're setting the classpath of project A that references external bundle X, then we would attempt to create the linked folder on A. This, of course, would be taking place at a time when the resource tree is locked, and hence our problem. Although the External Plug-in Libraries project's purpose is totally unrelated (designed to expand the Java search scope), and although it would be a big hack for the classpath computation algorithm to check it for linked folders, I nevertheless considered it, due to lack of better alternatives at this juncture. Here is the problem though, as I anticipate it: As I noted above, the External Plug-ins libraries uses a PDE container of its own (a different container than plug-in projects, but a container nevertheless). So here, we would run into a scenario where, in the midst of resolving the container for project X, we would be asking the container for the External Plug-in libraries to resolve initialize/resove itself. Having seen my fair share of classpath container troubles over the past few months, and unless the JDT guys assure me otherwise, I think this scenario would just open the gates of heck. I understand that days of manual tweaking of the classpath are gone, and users have gotten used to the luxury of a pde container that magically resolves all references to external/workspace plugins. But would it be unreasonable to ask people who want to use these bundles to add the class folder manually to their classpath until this funtionality becomes supported by PDE?
sigh. So just to be clear here, the linked folder can be in any project right? I was anticipating linking it in once in the workspace and than adding it to various projects classpaths rather than adding it to each project that required the plugin. So, if that is accurate, we could tell people "create a bogus project. explode all your target bundle jars. go to the bogus project and add a linked folder for each target bundle. For any project (workspace) bundle that requires a target bundle, add the corresponding linked folder to the classpath." Is there a way that this set of steps can be made easier for people?
More *sighs* from me. One issue I see with that approach is that PDE build does not recognize manually added entries on the classpath of the project. Would this prevent PDE build from building plugins that require "dot" bundles? I think PDE build may still work since it correctly compiles against "dot" bundles today so the extra entries on the project classpath should be ignored. But I don't currently see a way for the developer to manually add class folder that is linked to a directory that is outside the workspace without using a hardcoded path. There are no default classpath variables defined that the developer can base the link off of. It would be helpful if there was at least one classpath variable that pointed to the base install of eclipse. This would not be very good for .classpath files that are checked into a central repository because they would be specific to one developers environment.
>It would be helpful if there was at least >one classpath variable that pointed to the base install of eclipse. This we have. There is already an ECLIPSE_HOME variable that is managed by PDE and changes whenever your target platform changes. Although no longer used by PDE, it is still there for historic reasons.
While we are talking work-arounds, the following would (should?) work. This is more work than we want, but is simpler than fixing up all of the references. When you need to access a bundle from a jar, explode the jar (like we are doing today), and create a project that corresponds to the exploded bundle. Now other plug-ins can refer to this plug-in in the PDE expected way. Once/if we can access this directly at some point in the future, the extra project is no longer needed. Today it would be sub-optimal because we don't want to have these extra binary projects. (But it would work, modulo scaling issues - many binary plug-ins).
I did not see the variable when I went to link a class folder to an external folder. It's probably user error but it is not obvious to me how you do this.
regarding comment 26. Yes, in the end this is the easiest workaround. If we are already getting people to explode the bundles then adding them as a project is likely not a big deal. They should be able to add them as a binary linked project even. Tom/Wassim, can you confirm?
When I unzip the plugin from comment #5 into an arbitrary directory and import it using the plugin import wizard, its classpath looks good to me. Its Java Build path property page looks good. But the types this project contains do not show up in the Open Type dialog, for some reason. Philippe, could you please import the project into your workspace, and shed some light on what the problem could be..
Jeff, how about an enthusiastic +1 for RC3? By the way, I'm still experiencing the problem in comment #25. Any insight would be appreciated.
what exaclty are you wanting to do for this issue for RC3? I don't see a problem mentioned in comment 25. Was that a typo and you have not heard back from Philippe re comment 29? I am enthusiastic about doing something reasonably safe to at least enable minimal function in this area.
The only option that is still viable in 3.0 is to require people to import the plugins as binary (with or without links) into the workspace. This requires minimal, if any, changes to PDE code. When I tried it though with the current PDE code, I realized that, although, PDE is setting the classpath correctly of the imported plugin, JDT is not picking up the classes in the Open Type. So my follow-up was referring to comment #29, not comment #25. So if it's something that PDE needs to tweak when setting the classpath using class folders, then it's a low risk and would be a go for RC3 from us. If it's something JDT-related, then it's up to them to decide how/when to address it.
A hearty +1 for fixing this as described. It seems like it must be a mechanical problem somewhere. JDT clearly does allow the root of a project to be on the classpath and as you say, PDE is setting adding the class folder. Let's find and fix the mismatch.
Will try to spend sometime today to investigate again.
ok, here is the verdict. People will be able to import the blown-up plugins as binary project WITHOUT links and everything will be fine from a PDE point of view without any changes whatsoever at our end. Clients of the plugin can access code from the binary plugin. Note that the classes from the class folder of the binary project are available through code assist, but they are not available though the Open Type dialog, so there is a disconnect there, and I will therefore forward this defect to them to address this less important issue at their leisure. Also note that you CANNOT import the blown-up plugins as binary with links. This is because the classes are at the root of the project. If we were to play around with the project description to have it map to the external plugin, deleting the project from the workspace will result in the deletion of the actual plug-in in the install. This is where we will leave this for 3.0. Self-hosting using such plugins is supported as long as projects are imported as binary WITHOUT links. Will change the title of the bug report and reassign to JDT to address the Open Type problem.
Wassim, I was not able to reproduce the Open type problem. Looking at this bug, it seems that you fixed the PDE UI problem and that you found another problem in JDT Core (I'm not sure about that). But what is the problem in JDT Core ? No details was provided. What about closing this bug as a PDE UI bug, and providing steps to reproduce it in a separate bug ?
sure. opened bug 83822 to track the open type problem.
