Wednesday Jun 15, 2011

Migrating an Existing Extension to JDeveloper 11gR2 -- Part Two

We covered the basics of how to migrate an extension that does not use the Addin.initialize() method, in Part One of this topic. If you haven't taken a look at that yet, I strongly recommend that you do.

Quick review

With the release of JDeveloper 11g R2, the extension framework is now based on OSGi.  Because of this, we no longer load all of the extensions at the same time, at the startup of the IDE.  We now use something called Lazy Loading which only loads extensions when they are needed. Because Addin.initialize() is no longer called at IDE startup, you have to think a little more carefully about of how your extension integrates into the IDE. You can't just dump everything out there and have it ready to go.

I'm going to use the Extension SDK sample project, "OpenNodes" for this migration example.

A different point of view

The first thing we need to think about, is what user interface element can be used to trigger the loading of the rest of the extension. When we open the OpenNodesAddin class, which extends Addin, we see that there are two different things going on in the initialize() method.

A new factory object is being created and a call to a method called installViewMenu, which does exactly that.  It installs a menu item into the View menu. This is exactly what we are looking for.

If we move the functionality of this method to be done declaratively in the extension.xml file's trigger-hooks section, we will be able to show the menu item in the View menu, without actually loading any of the other code in the extension.  It will not get completely initialized until the menu item is selected. Go ahead and comment out the call to the installViewMenu() method and save the file.

The existing extension.xml file also contains an action element which will need to be migrated.  You can refer back to Part One for information on how to modify the action element and add the now required controller element as well.

We'll focus on the installViewMenu() method and how we will migrate it's functionality over to a menu element in the extension.xml file.  Here is what the existing method looks like

This is a pretty simple method that adds a menu item to the View menu on the IDE main menubar. It calls the only action that we have in the extension.xml file already. It doesn't have anything in the method that defines where the menu item is supposed to be placed within the View menu itself.  We can just do the same thing and let the IDE place the menu item in the default location if we like.

Let's move over to the extension.xml file now and add our menu element to the triggers section of the file. For this example, I have already gone ahead and done the migration of the action element, as well as the changes to the reuired-bundles element.

I'm going to go ahead and add the <menu-hook> element to the bottom of the <triggers> element, right after the new <controllers> element that we added.

The <menu-hook> element has one required argument of "xmlns".  We'll set this to ""

Once you have the menu-hook element started, you can use the xml schema tool in the Structure window, just as we described in Part One of this topic. We will need to add the following elements to finish the menu-hook section.

If you are not sure what values to use for the <menubar> id and <menu> id, you can refer back to a blog post I did early in 2011 about how to work with declarative menus in jdeveloper extensions.

The new trigger-hooks section is going to look like this when it's done.

We should be able to test the new version of the extension now, by doing the steps of:

-- Build
-- Deploy to target platform
-- Run Extension

The "Deploy to Target Platform" step is required in 11gR2 before you try the "Run Extension" feature.  This builds the OSGi bundle so that it can be deployed properly.

Cleaning things up

Once you run the new version, you should come across two things.

1) There is a warning telling you that "registerDockableFactory" has been deprecated, after you do the compile (I'm doing a rebuild when I see this)

2) When you actually run the extension, a Warning will be thrown telling you that the <feature> hook doesn't have a corresponding <feature-member>.

While everything will run fine with these warnings in place, lets go ahead and clean things up.

To get rid of the runtime warning, let's add a <feature-member> element just before we start the <trigger-hooks> section.

The registerDockableFactory() method is being replaced with a trigger-hook.  You can add this to the triggers element using the schema editor in the Structures window.  The class name and id will be required.

The result will look like this.

The last thing to do, is go into the OpenNodesDockableFactory class and comment out the method that does the existing registration.  Leave the ID variable declaration though.  That's needed by other parts of the code.

Now if we rebuild, deploy, and run the extension, everything should work without any warnings or errors.


By moving the GUI elements out of the Addin.initialize() method, we can display the connections that our extension requires for the user to enable the full functionality and start usng the extension. Once the trigger is hit, the IDE will call the Addin.initialize() method and do the rest of the loading of the extension.

There may still be cases where an extension needs to load, but doesn't have a GUI element to use as a trigger.  In those cases, there is usually something else that is being added to the IDE by the extension, that can be used as a trigger.  Take a look at the Trigger Hooks Wiki for a list of trigger-hooks provided by the IDE, and some more information about each of them.

As usual...  Comments, Comments, Comments.  Toss out your experiences and questions for others to learn from. All are welcome.

Monday Jun 13, 2011

Migrating an Existing Extension to JDeveloper 11gR2 -- Part One

With the new release of JDeveloper 11gR2, an extension that was written for a previous version of JDeveloper will no longer work.  There are a few changes that must be made to get things working again.  As with all development tasks, the work required can range from the very simple to extremely complex.  In this post, I'll cover the basics.  It should get everyone started in the right direction at least.

Your extension migration will follow these rough steps:

  1. Open your existing project in the 11.1.2 workspace
  2. Look at your existing extension and determine how it is integrated into the IDE. (e.g. Menu item, Wizard, etc.)
  3. If the integration point is coded in the Addin.initialize method, pull this out and replace it as a trigger-hook in the extension.xml file 
  4. If the menu or wizard hooks are already in use in the extension.xml file, move them into the trigger-hooks section. 
  5. Create an Action and controller class that will call the Addin.initialize() method when the action is called 
  6. Changes to the extension.xml file in regards to Classpath and dependencies will also have to be addressed 
  7. Make and Deploy to Target Platform to generate the file.

Open a copy of the workspace/project

NOTE: Make sure you are opening a copy of your extension source and not the original. This step can not be undone.

Make a copy of your existing extension source code and place it in a new directory that can be opened in the 11gR2 IDE.  Once you open the project, the IDE will ask to do some migration tasks that will bring the project and application files up-to-date with this version of the IDE.

How does the extension get initialized?

If your extension is already using a menu-hook, wizard, or context-menu-hook, in the extension.xml file for integrating with the GUI, you are in pretty good shape and there are only a few things that need to be changed to get things going again.

If you are using the Addin.initialize() method to register all of your menus, etc. then there is a little more work to be done.  It is the plan going forward, to completely remove the Addin.initialize() method and move everything to declarative hooks in the extension.xml or files.

I'll cover both situations in this blog topic, with Part One covering the non-Addin.initialize case, and Part Two extending to cover the rest.

Let's start with the SDK Sample project, "FirstSample".

When we look at this project we can see that none of the classes are extending the Addin class. We can also see that the menu setup is already being done declaratively in the extension.xml file.  This should make for a fairly simple migration.

I've made a copy of the FirstSample directory and placed it inside of another Application that I created in the 11gR2 version of the IDE.

When I open the project now, it brings up a migration wizard that looks like this.

I'll go ahead and just accept the defaults on the next couple of pages, then click on Finish.  The resulting dialog will look something like this.

 This process gets a few of the housekeeping things taken care of for the project itself.  It doesn't do anything to the source code of our project though.  That will remain the same.

Since we have already determined that we are not using any classes that extend the Addin class, we will only need to work with the extension.xml file.  I'll work through the file from top to bottom and show you what needs to get updated and how to go about doing it.


The <Classpaths> element has been deprecated in this release.  If it's in the extension.xml, it will just be ignored.  It has been replaced by a new element called <Required-Bundles>. The easiest way to make sure you are getting the proper bundle name when making these changes, is to use the Visual Editor for the extension.xml file.

Click on the Overview tab at the bottom of the editor window. 

Then click on the Dependencies menu.  It will look like this.

You can still see the entries that you currently have in your Classpaths element. We'll use these to get what we want in the Required-Bundles section.

Click on the + sign to the right of the Required Bundles section.  A dialog will popup with a list of all the available bundles. In the search field at the top of this dialog, type in the name of the first library that you currently have in classpaths.  "javatools" in this case.  This will narrow the list down to something that you can more easily select from. Go ahead and select the oracle.javatools bundle from the list. HINT:  Look at the slightly grayed out name under the jar files path.  This is the bundle name.  It will look like this when you're done.

 Repeat the steps above for the "oicons" bundle as well.

Once you have both of these added as Required Bundles, you can highlight the name of each Classpath entry, and then click the big red X on the right side of that section to remove this entry from the extension.xml file.

Clicking on the Source tab at the bottom of the editor, will get us back to the source code and the new entries should looks something like this

Go ahead and delete the remaining <classpath/> element from the file.  It will stop you from getting a warning at runtime.


 Next we are going to add the new trigger-hooks section to the extension.xml file.  This is what allows us to use lazy loading with our extensions.  An extension is not loaded until a trigger is hit that tells the IDE that you want to use this functionality, so load it up.

Once you've done this a few times, you can simply cut and paste code from other extensions that you have already migrated, but I want to show a little tool that can help when you're not quite sure where to start.

If you right-click on the <extension> element in the Structure window (lower right side of the IDE by default) you will see an option to "Insert Inside extension".  Select that option and go all the way to the bottom of the submenu and select "trigger-hooks".

Now right-click again, but on the trigger-hooks element this time, and insert a "trigger-hook" inside the trigger-hooks element.

You will notice that it places a nice clean <trigger-hook /> element in between the open and close <trigger-hooks> tags.  We need to change this to be an open and close tag instead of just the one tag.  If you delete the "/" from the trigger-hooks tag and then hit enter and type "</ " you will notice that the IDE will enter the close tag for you. The end result should look like this

You can see that this would have been a lot easier to just cut and paste in, but I wanted to show you that we do have a tool for working with the schema. We'll use this same tool a little later to add a Controller element which has a few more required parameters.


Now that we have the trigger-hooks structure in place, we can start moving some of our old elements up into this new area.  Since the Actions element is what most everything else references, let's move it in first.  Simply cut and paste the existing actions element from the <hooks> section up to the new <trigger-hooks> section.

We need to add an xml namespace to the <actions> element now.  The easiest way to do this is to click inside the <actions> tag just after the word "actions". Enter a space and then type " xmlns=" ". After you type the first " after the equal sign, a code completion pulldown should show up and give you a list of available namespaces to select from.  In this case, scroll down until you find, "  ".  Add the close " and you're done.

Controllers are now their own element in the extension.xml file, so we will delete the existing <controller-class> element from the actions element. The resulting actions element should now look like this


Controllers are a new element in the extension.xml file.  We're going to go back to the schema helper tool to add in our new controllers element.

Right-click on the <triggers> element in the Structure window and select "Insert Inside triggers".  Click Browse and scroll down the list until you find "Controllers". Click OK and then right-click on the new controllers element and follow the same steps to insert a controller element inside of the controllers. This is going to open a dialog asking you to enter the class for the controller.  If you start typing the package name for your controller, code completion will kick in and help you find the existing controller class.  It will look like this

 For this example, work your way down to the SimpleController class and click OK.

Let's keep adding the required elements to our new <controller> element.  Right-click on the controller element again, and insert an <update-rules> element, and then insert an <update-rule> element inside of that.  You will be asked for the "rule *: " when you insert the <update-rule>.  For now, just type in "always-enabled" for the rule.  I'll talk more about the new Rules system in another post, very soon.  The last thing to add is the <action> element.  Follow the same steps to insert the <action> element inside of the <update-rule> element.

You will be asked for the action id and label when you insert the action element.  You can copy the action id from the action element that we just added above. For this example it will be: "oracle.ide.extsamples.first.invokeAction"

You can set the label for your controller here as well, but it's not required.  Since we already have a label in our Action, I'm just going to leave this blank.  The final Controllers element should look like this

Context Menus

 Context menus are next in the existing extension.xml file, so lets take those on next.  The context menu element is a little different in the new release. Here is what the original looks like

We're going to use the xml schema tool again to get the new structure setup.

Right-click on the triggers element and "insert inside triggers".  Click Browse, then select the Context-menus-hook.  Enter "always-enabled" for the rule type when prompted.

Now right-click on the new context-menus-hook element, and insert a "site" element inside of this one.  You will be prompted for the "idref" for the context menus that you want to add.  In the original we had to created three different elements to cover all three of the main context menus.  Here we can enter all three as a comma separated list. 
Enter, "navigator, editor, explorer" and click OK.

Right-click one more time on the context-menu-hook, and insert an extension-listener element this time, inside the context-menu-hook element. Set the class name to be the same as what you had in the original elements. In this example, it would be, "oracle.ide.extsamples.firstsample.SimpleContextMenuListener"

The <extension-listener> element is optional. In this case, it works great because it just replaces the listener element that was already being used.  If you context-menu-hook uses the menu element instead of a listener-class element, do the steps below instead of adding the extension-listener element.

Now right-click on the menu element and insert inside of it, a section element. You can set the ID for this section to be anything you like. Once you have the section element created, insert an "item" element inside of it.  Set the "action-ref" value to the action id that we set above.  For this example it is: "oracle.ide.extsamples.first.invokeAction"

The new context-menu-hook element should now look like this id you used the <menu> element

 and like this if you used the <extension-listener> element

Notice that I still had to add an empty <menu/> element, since it is a required element.


The gallery element hasn't changed that much.  Copy and paste the original from the <hooks> element into the new <triggers> element.

 We only need to make a couple of changes to this element. We need to add an xml namespace to the gallery tag. Follow the same steps as above, where you clicked inside the tag, just after the name, enter a space, then type, "xmlns=" " when the code completion list comes up this time, select the same namespace as before,

Now we need to add a rule parameter to the <item> tag.  Type inside the tag, and add, " rule="always-enabled".  The new item tag will look like: <item rule="always-enabled">

We also want to add an <icon> element to the gallery element now.  This is pretty simple.  Just add the line:


 Everything else should stay the same.  The new gallery element will look like

Menus and Toolbars

The <menu-hooks> element is even easier then the Gallery hook.  Copy and paste the entire <menu-hooks> (including menu and toolbar hooks) element into the <triggers> element.

All we have to do is add an xml namespace to the <menu-hooks> tag.  Set this to " xmlns="" "

Once you have all of these elements moved from the Hooks element to the Triggers element, the only thing left in the Hooks section should be the <features-hook>. This can be left where it is.  The <hooks> element does still get called by the extension framework.  It is called as the extension is loaded.  The best way to decided if something belongs in the <triggers-hooks> element or the <hooks> element is to think about when that information needs to be available to the IDE.  If it's something that has to show up before the extension is actually loaded, then it should be in the <trigger-hooks> element.  Otherwise, it's fine to leave it where it is.


That should do it for migrating this extension.  To test everything and make sure it really does work, you need to follow these three steps.

1) Build the extension
This is an obvious step and of course it should compile without any errors.

2) Deploy to Target Platform
This is a new step that must be run every time before you can perform the "Run Extension" menu option.  It builds the file and packages everything properly. Rick-click on your project and select this from the menu down in the Extensions section.

3) Click on Run Extension
This performs the same as it always has. It will open another instance of the IDE with your extension installed and, hopefully, running correctly.


In Part Two I finish the migration steps by showing how to handle migrating an extension that extends the Addin class. You will still need to do all of the work that we have just shown above, but there is a little more work to do as well.

Comment are always welcome, and encouraged.  Everyone learns more when a good conversation is started!


profile image
My name is John 'JB' Brock.
This Blog will focus on tips and tricks for working with the JDeveloper Extension SDK.
I hope to bring clarity to some of the mysteries around developing extensions for JDeveloper.


« July 2016