[galileo] Cool Views to control Plug-ins (Target Platform)

Part 8 of my Galileo Reviews around Target Platforms. An Overview of this blog series can be found here.

This part is a direct follow-up of part 7 where we talked about viewing @ Plug-ins defining your running IDE. If you don’t have read part 7 please read it first.

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:

plug-ins select option

Right-clicking on a Plug-in you get some more selections:

plug-ins select rightclick

useful is to select the Required Plug-ins, per ex. for org.eclipse.riena.ui.ridgets:

plug-ins select required

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:

duplicated plug-ins

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 …

ghosts 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:

target platform state

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

target platform state location

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.

target platform state imports and supplier

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:

target platform state options

You can show only the leafs or unresolved plug-ins.

If there are unresolved plug-ins you get the info whats missing:

target platform state unresolved

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:

plug-in dependencies view actions

  • 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)
  • options
    • 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

plug-in dependencies focus on selection

hitting OK displays the Dependencies – wether the required Plug-ins (Callees)

plug-in dependencies hierarchical required by

or the Plug-ins requiring the selected Plug-in (Callers)

plug-in dependencies hierarchical requiring

Right-clicking on a Plug-in allows you …

plug-in dependencies right click

  • 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:

graph plug-in dependencies toolbar

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:

graph plug-in dependencies example

How this graph looks like depends on some options you can select:

graph plug-in dependencies options

and also the Zoomfactor

graph plug-in dependencies zoom

There’s also a great Search Option:

graph plug-in dependencies search

All Plug-ins displayed matching the Search Pattern are colored yellow.

graph plug-in dependencies search pattern matched

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 ;-)

3 responses

    • Jan,
      you can’t open this site in a browser
      you have to add this URL as new SoftwareSite inside Eclipse
      (there you can also test if the site is available)
      Then you can add new software from this site
      ekke

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,067 other followers

%d bloggers like this: