Community
Participate
Working Groups
users of PDE are inherently manipulating a set of plugins in a State. That state is resolved and various bundles are wired together. From time to time the wirings go wrong or are unexpected. When this happens it would be good for users to inspect the state and follow the wires and diagnose the problems. This is very much like the functions provide in the OSGi console (e.g., ss, diag, package, ..) but on the PDE state not the framework's state. The Equinox team would be delighted to supply any underlying infrastructure needed in addition to the state helper etc and humbly request that the PDE UI wizards expose this somehow in the UI.
I would almost want to tie this into the bundle management plan item we have. It would be nice to have a UI "console" that you can inspect an environment.
This is certainly a very useful function. I believe PDE already has all the information on what is wrong with the state. The challenge is in the UI rendering of the state. That is, what you want is really a real-time version of the 'validate plug-in set' that we have on the Plug-ins tab of the PDE launchers. However, if you observe how we report the errors there, it is easy to see that a tree viewer can only do so much. It is very hard to clearly render a chain reaction with a tree viewer. We were planning on doing alternative explorations to visualize dependency graphs and states, but the effort is currently blocked (bug 155494).
Note also that our coop student Richard Keelan has adapted the regular framework console commands that look at the state to work on the PDE state. This surfaces as a "PDE Console". I believe he has something to show for this now. Perhaps he can attach the code here or link to another bug that has the code.
Created attachment 52958 [details] Plugin mentioned by Jeff in Comment 3
Thanks Richard, I will give it a whirl. Jeff/DJ, I think Richard should be punished (severely) for not using the PDE export wizards to export his plug-in.
I was wondering about that too. How can you tell that he didn't? Either way we should punish him. Hmmm, perhaps a cage match...
It was a tough call: The way the src code is intermingled with the class files inside the archive does look like it was done with pde/build. However, the archive's extension is ZIP, instead of JAR. Since PDE never packages an individual plug-in in a ZIP, and I find it unlikely that the accused renamed the archive's extension after-the-fact (why would he? no need/motive to do that), we have to assume he used alternate tools.
In hopes to avoid too much punishment, Richard will attach a new attachment to this bug later today. The attachment will: - be in JAR format, the results of exporting using PDE - contain additional commands to be used in the PDE console (bundle, headers, and packages)
I exported it as an Archive file, because someone (Not DJ, for reference) told me to do it that way. I was just following orders; however, since I can't reveal who exactly told me to, I take full responsibility, and will gladly take a cage match.
Created attachment 53304 [details] Updated bundle This is my final update for this plugin. Feel free to review and release. Some functionality that might be missing includes: *pde_bundle doesn't provide information on services used, and services provided. *pde_bundle can't tell what the required bundles are for a plug-in that is in the workspace. *pde_packages doesn't list the bundles which import each package exported by the bundle specified in the command.
the last missing function point is unfortunate. Is this information not available?
"*pde_bundle can't tell what the required bundles are for a plug-in that is in the workspace." Richard, why is this not possible? This info is readily available. just right-click on a workspace plug-in project and select PDE Tools > Open Dependencies from the context menu.
I should clarify; I didn't meant that those three things weren't possible, just that they haven't been done.
Would it make sense to try to tie state information for all the bundles into the plug-ins view? I figured we could put the little red X on plug-ins who have unsatisfied constraints and could display the errors in the properties box. Specifically what information do we want to display from the State?
basically we want to show all the resolver errors from the current PDE state. The Plug-ins view now show a list of plug-ins, with directory structure, where applicable. The problem here is that mixing directory structures and resolver errors may be confusing.
We could create another view (which could be possibly be reused for extreme self hosting). I just wanted to avoid having a view overload. If possible, I would like to try to display this information through a UI instead of a console. I hate trying to remember commands :)
Brian, unsatisfied constraints, which what we are trying to show here, are for the most part unsatisfied dependencies. So the 'Plug-in Dependencies' view seem like a reasonable place for this work. Realistically, extreme self-hosting can't be contained in 3.3, what will all the recent real estate action in Austin.
I believe this is dependent on the console changes in bug 162415.
This dependency won't be necessary. we plan to show the state's resolver errors in the Plug-in Dependencies view in a tree format.
Adding this to the list for Views Theme Week.
*** Bug 88578 has been marked as a duplicate of this bug. ***
We added an extra section to the Plug-in Dependencies view. To see the 'state of the state', open the view and select the right most icon (looks like two plugs). This will hide the other icons on the toolbar and will open up the current contents of the state. To go back to the other views, simply click the icon again and it should return to the tree/list which was previously displayed (if any). To aid in the resolution of problems, there is also a filter on the 'state of state' view to show only unresolved plug-ings.
OMG, this is so nice, I see what bundle every imported package is wired to and everything :)
