Community
Participate
Working Groups
The Plug-in Manifest Editor's Dependencies page's "Automated Management of Dependencies" section contains a very useful capability to compute a bundle's runtime dependencies. This is achieved by populating the list of candidate reference bundles, choosing how you wish to describe the bundle's dependencies (either Require-Bundle or Import-Package") and clicking the "add dependencies" link. It is unfortunate that the editor's dependency calculation does not find any reference that is a "discouraged access", which typically occurs when referencing a type that lives in a package that is exported as "x-internal". The dependency is never detected, even when you turn the "Discouraged reference" compiler preference down to "Ignore". I would therefore like to see the "add dependencies" calculation fixed to include all dependencies that the bundle requires, regardless of whether they are a regular export or an x-internal export. The fact that the bundle has a code dependency implies that a Require-Bundle or Import-Package entry is required at runtime. A required bundle or imported package that is part of an "x-internal relationship" should be decorated in the Plug-in Manifest Editor with a warning icon, and configurable as Ignore/Warning/Error. This will lead the developer to go and review the providing bundle, and possibly changing the exported package to either an "x-friend" or to a regular exported package.
This is something we can look at in 3.5
Steps to reproduce: 1. Extract the attached 237681-bar.zip into your workspace and imported it as an existing project. 2. Extract the attached 237681-foo.zip into your workspace and imported it as an existing project. 3. The bar project contains launch/bar.launch. Running this launch will start the OSGi framework with the bar and foo bundles installed. 4. At the OSGi console, type ss: osgi> ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20080427-0830 1 RESOLVED bar_1.0.0 2 ACTIVE foo_1.0.0 5. Notice that the bar bundle is only RESOLVED. This is because the bundle failed to become ACTIVE, so it rolled back to RESOLVED. 6. To understand what went wrong, type "start 1" at the console. You'll see a bunch of exceptions similar to the following: java.lang.NoClassDefFoundError: foo/internal/Foo at bar.BarActivator.start(BarActivator.java:10) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:1009) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:1003) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:984) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:346) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:265) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:257) at org.eclipse.osgi.framework.internal.core.FrameworkCommandProvider._start(FrameworkCommandProvider.java:257) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.osgi.framework.internal.core.FrameworkCommandInterpreter.execute(FrameworkCommandInterpreter.java:150) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.docommand(FrameworkConsole.java:302) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.console(FrameworkConsole.java:287) at org.eclipse.osgi.framework.internal.core.FrameworkConsole.run(FrameworkConsole.java:223) at java.lang.Thread.run(Thread.java:595) 7. The PDE tooling should not be allowing me to run with a bundle that fails miserably. The problem, of course, is a missing dependency in the bundle's manifest. 8. Kill the runtime. To resolve this problem: 1. Use the Plug-in Manifest Editor to open the bar bundle's manifest. 2. The "add dependencies" link does not work, so you'll have to update the bundle's imported packages by hand. 3. Turn to the Dependencies page of the editor. 4. Under Imported Packages click the "Add" button and enter "foo.internal". 5. Save the editor. 6. Rerun the launch configuration and you'll see something like this: osgi> foo.internal.Foo@1807ca8 7. Type ss on the console to see all the happy bundles: osgi> ss Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_3.4.0.v20080427-0830 1 ACTIVE bar_1.0.0 2 ACTIVE foo_1.0.0
Created attachment 105333 [details] Example bundle project: bar
Created attachment 105334 [details] Example bundle project: foo
"7. The PDE tooling should not be allowing me to run with a bundle that fails miserably. The problem, of course, is a missing dependency in the bundle's manifest." Simon, if you validated your launch configuration, I think PDE would catch this problem as it builds a state and the state would complain. However, validation on the launch configuration is disabled by default as constructing a state before launch could be expensive.
Sadly, Chris, validation does not detect the problem, and I agree that it should. But this sort of problem should also have been flagged earlier in the editor too.
+1 for fixing this. There are whole bundles have have only provisional API (i.e., markded as x-internal:=true) (think p2). With the current state, users cannot use AMD but there are no clues that they cannot. Suggest simply considering all sources of the desired types and let the developer deal with any error/warnings related to access restrictions.
The other gotcha, which I did not mention previously, is that the computation only considers packages that have been exported by other bundles. This dictates the order that you do things... bottom up, rather than top down. You should be able to add a package as an imported package even if it is not exported by anyone... In this case you should see a warning against the bundle that imports the package. The validation before launching should also detect an imported package for which there is no exported package. The warning against the bundle that imports the package, of course, is really a hint to go and find a bundle that contains the package and have it export the package. I hesitate to suggest adding a warning against the bundle that contains the package since it might never intend to export it, plus there could be multiple bundles that contain the package, and this would lead to a prolification of warnings and to confusion.
Ankur, are you willing to try this one out? I have a Mylyn context if you want.
I will look into it tonight and get back if I have any doubts/questions. Btw, am not sure what a Mylyn context is and how to use it. Any quick pointers?
Mylyn is an Eclipse plug-in that facilitates a task-oriented workflow. One of its major features is tracking your context, all the files that you have opened/worked on during a task are stored, you can switch between tasks and always have the right files opened. Chris can attach his context to this bug and you could import it into mylyn, opening all the files Chris considered relevant. http://www.eclipse.org/mylyn/ Chris, myself and some of the PDE contributors use it, it's worth giving it a try some time.
Chris, can you please attach the Mylyn context?
Please can this bug gets fixed for Galileo. It causes people to not want to use PDE's "Automated Management of Dependencies" support. Thanks.
+1 Even though I usually only use x-internal packages from test projects, this change will mean that the tooling more closely follows the intent of x-internal.
Ankur, definitely keep this bug in mind if you need a change from the target platform work. Pinging Chris, could you whip up a mylyn context for this?
To confirm my understanding of what needs to be done. 1. When "add dependencies" is clicked, even the packages marked internal shall get added (if referenced). 2. On the "Manifest.MF" page, that imported package you have a marker saying that it an internal package. 3. As a quick fix, only option provided will be to delete that entry. Let me know if missed something.
That sounds fine, although I'm not fussed about the quick fix. I really hope that we can get this into Eclipse 3.5.
Created attachment 133724 [details] Patch without QuickFix
Simon, Paul, can you take a look at this patch and see if it solves your problem? The fix looks extraordinarily simple for what this bug was describing. It also looks like it won't add a marker to flag the internal/provisional packages.
Let's try to get this one in for Friday's build.
done. > 20090507 Thanks for the patch!
Created attachment 134855 [details] mylyn/context/zip
I think Simon will be pleased.
+1
I shall download the next build and give it a try. Thanks very much!
I have verified this using I20090514-2000. It works great, thanks.
