Community
Participate
Working Groups
Hi, I have a bundle with additional filesystem content which is deployed "unpacked", i.e. as a directory. The bundle's classes are not compiled into a jar file but the classes are directly in a folder (com/company/etc..). This bundle is deployed in my running eclipse and performs as expected. No problems running nor any other problems. If I create a new bundle and include former bundle as a dependency it is not listed in the "Plug-in Dependencies" tree node and I do not have access to my classes. The only way to force the classes to be recognized is by adding the bundle as a folder to the build path in the project properties. Now this is quite inconvenient if the bundle is a bundle from a remote site added to the target platform. I think I can solve this by letting the build create a jar by specifying source.library.jar = src/ output.library.jar = bin/ instead of source.. = src/ output.. = bin/ Is this normal? I am testing this on a 3.6.1 in Ubuntu.
If I import the bundle from the plug-in registry view, it is added as expected to the "Plug-in Dependencies" tree node and has an open folder as icon.
So you have a unjarred bundle in your target platform? I am able to add dependencies on unjarred bundles ok using code from 3.7 (and it is unlikely that something significant like this would go unnoticed in 3.6.1). How are you adding the dependency to your project?
(In reply to comment #2) > So you have a unjarred bundle in your target platform? I am able to add > dependencies on unjarred bundles ok using code from 3.7 (and it is unlikely > that something significant like this would go unnoticed in 3.6.1). How are you > adding the dependency to your project? Hi Curtis. I agree, this is very unlikely. Yet it happens and it drives me crazy. I have since tried to place a jar in the unjarred bundle (as a library) but that did not solve it. I will try to reproduce the situation with some simple bundles and post the results back.
Hi, I have isolated my plug-in and stripped some of its packages. I created a feature and installed, created a repo and installed this in a fresh 3.6.1 eclipse on ubuntu. java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) Server VM (build 17.1-b03, mixed mode) Eclipse build: M20100909-0800 See the screenshot for a first impression. It shows a plug-in in the workspace that imports the bundle nl.remain.core. The plug-in dependencies show no evidence of the plug-in. The source that is created to the right cannot complete the package nl.remain.core.logging that this bundle is supposed to be exporting (as can be seen in the console where you can see that the bundle is active and exports the package) I am not using a target environment other then the running. I will also attach the p2 repo that contains the feature and the plug-in. If this proves to be a bug than I want a nomination for "best bug before christmas". If I am wasting your time I will send a bag of "dropjes" to make up for it.
Created attachment 185682 [details] Screenshot with comments
Created attachment 185683 [details] Configuration log
Created attachment 185684 [details] the p2 repo containing the feature and the bundle
Created attachment 185685 [details] The sources The feature and the bundle source projects.
I have found the problem. I do not specify anything in the "Classpath" field in the "Runtime" tab of the manifest editor. This is causing the described symptoms. If I enter a "." in this field and deploy the plugin then PDE is able to resolve it and place the bundle in the "Plug-in Dependencies" field. The running platform is fine about this and will resolve the bundle and use all classes but PDE build is having problems with it. The fields hint states: "Specify the libraries and folders that constitute the plug-in classpath. If unspecified, the classes and resources are assumed to be at the root of the plug-in." My classes are at the root of the plug-in. At least if you count the packages as part of the class. So I did not specify anything (which is the default). I was assuming that this would resolve the package.class (and because equinox runtime is implementing it like this.)
I would expect the PDE to resolve the bundle in the same way as equinox does it. If this is not possible then maybe it is possible to give out some warnings? PDE should not ignore the required bundle as silently as it does now. It should at least place a warning next to the required bundle stating something like "there is no classpath specified for bundle x.y.z." This also happens on Windows7_64
I have resolved this by specifying a library on the "Classpath" field in the manifest editor and letting the build create the classes in there. All in all this is the better solution but it sure took me a lot of time to figure this out and I am convinced that PDE should be able to handle the "unjarred" plugins without a specific library in the directory. Can anybody give some thoughts on this?
Andrew, can you please take a look at this when you have some time? I'm a bit confused as to where the problem is coming from (or if this is expected behaviour). If I remove the '.' classpath entry from one of the sdk bundles, everything in my workspace continues to work, but exporting the plug-in results in a bundle with no classfiles.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
