Sunday, May 31, 2009

Target Platform State view : wish-list

In previous post we discussed the new Target Platform State view. I feel the view can be enhanced more and can be leveraged as a quick watch on the active Target. In 3.6 I would like to see
  1. the view displaying the name of the active Target (276981).
  2. acting as a quick launch to Edit Target Definition wizard.
  3. a "collapse all" button.
  4. How about color highlighting the plug-ins referred by workspace plug-ins?

Give it a try and let us know your wish-list.

Saturday, May 30, 2009

[New in Eclipse 3.5] Target Platform State view

The new target story in Eclipse 3.5 allows you to have multiple targets in your workspace. With this one really needs a means to see what constitutes the active target definition. For this reason, we now have a new view - Target Platform State (I don't like to call it TPS view :-)). It can be found in Window -> Show View -> Other... -> Plug-in Development -> Target Platform State.

This is how it looks like


Target Platform State view

What is it good for?
The target platform state view displays the bundles selected by the active target definition. And also their version and the location they are getting picked from. Thus, if you are facing an issue such as plug-in dependency not getting resolved as expected or wrong version of the plug-in getting picked up, the target platform state is where you should be looking.

It also displays, for each plug-in, the required plug-ins and the packages it imports and from where.



Required Plug-ins and Imported Packages
The view is a filtered one.



view filtered for org.eclipse.pde.ui

And when the "Show only unresolved plug-ins" menu choice from the view menu is used, the view only those plug-ins are shown whose dependencies can not be resolved. With all dependencies resolved this one should show a blank view. The "Show leaf plug-ins" will show only those plug-ins on whom no other plug-in depends. They are the leaf of the dependency tree.


Target with only Mylyn plug-ins without Eclipse SDK

Thursday, May 28, 2009

[New in Eclipse 3.5] VM Arguments can be now imported to Target Definition

The Target Definitions have environment settings which are used as template to create launch configurations. One such setting is the VM Arguments (discussed in more detail here). The VM Arguments are used to tune the JVM and one of the most commonly used arguments are -Xms and -Xmx (minimum and maximum heap size). Thus, if a heap size is specified, it will then be used to initialize the launch configurations. That is, the same VM arguments are copied.


Import Arguments wizard
In 3,5, the VM Arguments section comes with an Import Arguments wizard. It collects and displays VM arguments from all the bundle containers that form that particular target definition. A general assumption used to be that the VM arguments will be reflected in the target and launch configurations automatically. Because there could be conflicting values, Eclipse can not be sure which one to pick. That is why the arguments were left at developer's discretion. Since the expectation was to get the same values for arguments, we now have the import wizard that simplifies this copy-paste.

The Import Argument wizard is available both on Environment page of Target Editor as well as Arguments tab of  Edit Target Definition wizard.



Arguments section on Environment page of Target Editor
The Edit Target Definition wizard gets invoked when "Edit..." button is clicked on Target Preference page.


Import Arguments wizard

Clicking OK on Import Arguments wizard inserts the selected arguments in the arguments text box. It does not checks if they were already present.

Tuesday, May 26, 2009

Source Bundles

These links are good read to know more about the Source Bundles and a bit of history behind.

Exporting source bundles

PDE in Eclipse 3.5 has a new enhancement to export source bundles. Earlier you could only include the source code inside the bundle. But now the source code can also be exported as a separate bundle. Eclipse can recognize it and associate it with the binary bundle. The source code bundles are very easy to identify for they have source in their name. A plug-in org.my.plugin_1.0.0 will have the source bundle as org.my.plugin.source_1.0.0.


How to:

The export process remains the same. But now you have a combo box where you can choose how you want to include the source code - Inside the bundle or as a separate bundle.


Export Wizard

The source bundle option is available while exporting plug-ins as well as for features and product projects.

Monday, May 25, 2009

How to add context help to an editor?

Short Steps:
1. Create a context help file and add a context id to it.
2. Extend the o..e.help.contexts and point it to this file
3. Associate the editor to the context help by calling setHelpContextId

How to:

1. Create a context help file and add a context id to it.

Use File -> New and choose Context Help. Give it a meaning full name. In PDE contexts_PDE.xml (in o.e.pde.doc.user) contains contexts help ids for PDE UI stuff while api_contexts.xml for API Tooling.

Add a context to it and name it like editor_main_page. Give some description


Context Help Editor

2. Extend the o..e.help.contexts and point it to this file

Add an extension org.eclipse.help.contexts (this will add a dependency to o.e.help). Add a new contexts to it. In the details section, point it to the context file created above.



Extension page


3. Associate the editor to the context help by calling setHelpContextId

In your editor class call setHelpContextId to associate the editor to the context help editor_main_page.

public XMLEditor() {
super();
colorManager = new ColorManager();
setSourceViewerConfiguration(new XMLConfiguration(colorManager));
setDocumentProvider(new XMLDocumentProvider());
setHelpContextId("my.editor.sample.editor_context");
}

Saturday, May 23, 2009

Hello world!

Well this being the very first post of the blog, it has to be "Hello world!". But what follows, I hope, is something better :-)