Part 8 of my Galileo Reviews around Target Platforms. An Overview of this blog series can be found here.
Now we want to look in detail at your Target Platform Plug-ins.
Remember: if you didn’t defined a Target Platform definition, then your running IDE is also Target Platform – which means you’re exploring the same set of Plug-ins.
2. View @ Plug-ins defining a Target Platform
The Target Platform – Plug-ins are always from the “active” Target Platform. If you want to take a look at Plug-ins from other Target Platform Definition you can take a look at the Content or you have to set a Target Definition as “active”. (You know from last blogs that you can switch the active Target Platform even from the Target deefinition File Editor)
2.1. Plug-ins View
The Plug-ins View lists all Plug-ins (Bundles) from your current Target Platform:
- all Plug-ins from Target Platform Definition
- and all Plug-ins from Workspace
In the top right corner you can select which Bundles should be displayed:
Right-clicking on a Plug-in you get some more selections:
useful is to select the Required Plug-ins, per ex. for org.eclipse.riena.ui.ridgets:
Open Dependencies opens Plug-in Dependencies View showing the “Required Plug-ins” (Callees)
Find References also opens Plug-in Dependencies View showing the Plug-ins “requiring the selected Plug-in” (Callers)
More details about the Plug-in Dependencies View see below (2.3).
Confused by duplicated Plug-ins ?
After some work with different Target Platforms, switching between them perhaps suddenly you are confused exploring the Plug-ins View:
uuups – so many bundles are listed twice or more. Exploring the Bundles you’ll see the entries are pointing to exactly the same Bundles / versions / Location. Unchecking “Show Disabled Plug-ins” will reduce those duplicates, but some still remain.
Congratulations – you are fighting against …
Ghost Bundles: Restarting Eclipse after switching between some Target Platforms causes many Bundles to appear more then once. For more informations see Bugzilla 277611 Doing a Reload of the current Target Platform helps – but after Restarting Eclipse the ghosts are back. This should be fixed in 3.6. At the moment just ignore them.
2.2. Target Platform State View
This View is new to Eclipse 3.5 Galileo – thx to PDE UI Team: you did a great job:
For each Bundle (Plug-in) you get the Symbolic Name, the Version and the Location from where P2 the Bundle gets.
In the example above the Location is
the most important part of the location path is .bundle_pool – thats one of the secrets of P2: all fetched Bundles are stored into a Bundlepool. This Bundlepool is shared between all of your Target Platforms – so P2 only has to download bundles from Software Sites if there’s a newer one or its the first time needed by a Target Platform.
Hint: Its good to know where the Bundlepool is stored, because if one day you have trouble with your Bundlepool – stop eclipse, delete the Pool and restart / reload your Target Platform and all will be created new. But from my experiences while going thru some Milestones and many nightly builds of Eclipse 3.5 I never had to do this: P2 was very stable and even survived some crashes.
BTW: if you’re looking at the directory of .metadata and .bundle_pool and you dont see it under OSX, then you have to make hidden and system files visible. How this can be done is described here.
The Target Platform State also displays information about the Dependencies:
- Required Bundles
- Imported Packages
Whats great about the Imported Packages – you not only see which packages are imported, you also see which bundle is the Supplier of the package – so you get informations how OSGI wired the bundles.
Double Clicking or Right-Click Open on a bundle or Package-Import opens the MANIFEST.MF file for the selected Bundle or the Supplier if clicked at a Package.
At the top right corner of Target Platform State View you can select some options what to display:
You can show only the leafs or unresolved plug-ins.
If there are unresolved plug-ins you get the info whats missing:
For me the new Target Platform State View is a great enhancement compared with Ganymede.
2.3. Plug-in Dependencies View
The Plug-in Dependencies View can be opened from Plug-ins View (see above 2.1) or you open the View directly.
From the Toolbar of the View you can select:
- set the Focus on… (the root)
- collapse all
- show Callees (required plug-ins) || show Callers (plug-ins requiring the selected plug-in)
- set hierarchical layout || set Flat Layout
- show cycles (we’ll talk about cycles in another blog of this series)
- show previous (a history of last Root objects you focussed on)
- show Fragments (if unchecked, fragments will not be displayed)
- show optional Dependencies (if unchecked optional dependencies will not be displayed)
set the Focus opens a Plug-in Selection View
hitting OK displays the Dependencies – wether the required Plug-ins (Callees)
or the Plug-ins requiring the selected Plug-in (Callers)
Right-clicking on a Plug-in allows you …
- to Open the MANIFEST.MF editor
- change the Focus to the selected Plug-in
- open the Focus on… selection again
If you like to work with Dependency – trees this view is an easy way to go thru the Dependencies between Plug-ins (bundles).
But if you prefer a graphical View of dependencies you should read on…
2.4. Graph Plug-in Dependencies View
The Graph Plug-in Dependencies View has a Toolbar similar to the normal Plug-in Dependenciesw View:
you can Focus on…, switch between Callees and Callers, go previous or one Plug-in forward, make a screenshot and the options let you set a Zoom factor.
If we focus on the same Plug-in as above (2.3) your graph can look like this:
How this graph looks like depends on some options you can select:
and also the Zoomfactor
There’s also a great Search Option:
All Plug-ins displayed matching the Search Pattern are colored yellow.
I encourage you to open the View, play something around to see how the different options change the graphical output.
Its also a great idea to take a screenshot (clicking on the camera in the toolbar) and integrate this into your documentation or so.
I really like this View because it helps much to understand dependencies.
The next blog entry of this series of Galileo reviews is around Troubleshooting – many unwanted things can happen