Community
Participate
Working Groups
Created attachment 190523 [details] Fix proposition Currently PDE explicitely ignores external jars from JDT model. This is a little bit inflexible, as people expect more freedom in bundle composition during development time.
Created attachment 190524 [details] Bundle for testing with 3.6.2 Please place the plugin in dropins. The difference is not noticeable in Eclipse.
Will investigate for M7.
My patch is not complete. BundleErrorReporter checks if all jars are inside a plug-in and reports errors if any is missing.
Created attachment 190863 [details] Patch for getting the external jars included while exporting packages The behaviour is controlled by setting the system flag org.eclipse.pde.allowExtLibsInOSGI
Created attachment 190868 [details] Complete patch which also controls when manifest.mf should show an error. if the external jars are allowed, then it will check if the package is in the external jar. It is assumed that the user is responsible for proper packaging.
I tried to get rid of the dependency on the system variable, but this does not look easy, because we cannot control this kind of behaviour from Eclipse UI. PDE lacks support for flexible resource location, so adding a check-box anywhere will cause a lot of confusion. It will be hard to explain that you can depend on external jars, but there is no way of adding external jars to the plugin. So we have to think of a solution which: * will be project specific * will have no UI in Eclipse * will be configurable by 3rd party * will be off in Eclipse by default The only solution that meets all those requirements is a project specific preference. Are you guys all OK with that?
Sounds fine to me.
Created attachment 191659 [details] A patch which will use project specific settings
To enable an external jar support in a project you have to set a project preference using the code: ProjectScope scope = new ProjectScope(proj.getProject()); IEclipsePreferences node = scope.getNode(PDECore.PLUGIN_ID); if (node != null) { node.putBoolean("allowExtLibsInOSGI", true) }
I have been trying to come up with a better solution solution to this, but no luck so far. For 3.6 patching, supporting a project setting is acceptable. However, going forward, adding options like this one make PDE harder to maintain.
I should be able to flag containers( not the whole project) if I would like to allow external jars to be exported. Each project can have multiple containers in the classpath and some of them are third party or PDE Dependencies. As an owner of a container I can decide along with if I want my jars in the container to be exported with the project, and if I want to be able to export any packages from the jars inside the container.
(In reply to comment #11) > I should be able to flag containers( not the whole project) if I would like to > allow external jars to be exported. Each project can have multiple containers > in the classpath and some of them are third party or PDE Dependencies. > As an owner of a container I can decide along with if I want my jars in the > container to be exported with the project, and if I want to be able to export > any packages from the jars inside the container. This bug is about where PDE expects the jars for a bundle-classpath entry to be. It is not related to exporting.
Some thoughts: A workaround is to add the library to the project as a linked resource. It is still an external jar. However, you can then add it to the classpath as a local jar file (which gets picked up by PDE). There is a deeper problem. The exported packages / calculate uses / etc options take whatever JDT supplies them with. We do not consider that is actually on the bundle classpath. So if you add a jar to the JDT classpath, you can add packages to the bundle's export list and PDE will be perfectly fine with it. None of those packages will be available at runtime because they aren't specified on the bundle classpath. It would be better to make the logic more clear. Looking at the code and the Eclipse projects in my workspace, I think it would be more appropriate to check the classpath container the fragment roots are coming from, not whether they are local/external or even archive/directory. If we take this approach, we would then have to decide whether to use a black list or a white list for the containers (we need to avoid the jre container, some extenders may want their container included, while others may not).
The proposed patch might work for that specific case but the fact that we can't find a good UI integration makes me think that more work needs to be invested here. Also, the whole PDE tooling including API Tools needs to be tested so that we are sure we don't break anyone. To me this looks like a bigger item that should be done in 3.8. Christopher, please try whether using linked (or even virtual) resources is an option.
WTP can flag entries, although only in its domain. Adding Tim to CC, maybe he will tell more about those flags. I agree it is too big for 3.7 (new API may be required). The question is if it can & will be done during 3.8? It looks like a significant amount of work with barely noticeable effects.
> It looks like a significant amount of work with barely noticeable effects. Mmh, so why do you think your small patch fixes the issue?
> Adding Tim to CC, maybe he will tell more about those flags. When WTP configures a project (PDE or otherwise) it knows exactly which jars are part of (included in) a project vs external dependencies. It uses a JDT classpath attribute to mark each entry, but since neither JDT or PDE have this concept it uses a WTP-specific key.
(In reply to comment #16) > > It looks like a significant amount of work with barely noticeable effects. > Mmh, so why do you think your small patch fixes the issue? Because I have tested it ;-). My approach is really simple: if a project claims it supports external jars, then process them. I think that the suggested approach is: annotate claspath entries with pde marker during plugin creation process only annotated classpath entries (and VM libraries)
Moving to 3.8. A proper fix here should involve some sort of public API. It should be more flexible than just supporting external jars on the classpath. Having a special classpath attribute might be appropriate. The PDE editor could easily set the property. However, there is no way for the user to modify that attribute except editing the classpath file).
On the other hand, making pde related classpath entries introduces risk of breaking the compatibility. Existing projects without pde marks cannot be automatically migrated, because we do not know what should be marked. So only newly created projects may support pde marks, and therefore they have to be marked somehow that they support those marks. Maintaining two kinds of configuration and new API will be rather difficult, because every project dependent on PDE will have to support both approaches. It looks like a fundamental approach change, doesn't it.
This is no longer on the 3.8 plan.
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. If the bug is still relevant, please remove the "stalebug" whiteboard tag.
