Friday Nov 11, 2011

Attention Extension Developers: Your input wanted!

Your Input Wanted!

I've posted a lot of different topics throughout 2011, and would really like to provide info that is most important to you, the extension developer, as we head for 2012.

What are the most important areas that you want to learn more about?

Post your requests for examples and topics in the comments section. Let me know what you are struggling with, or something that you worked out, but it took way to long to figure out.  I'll take the list and do my best to provide samples over the coming months.

Please provide the version of JDeveloper that you want the topic to cover.

Remember:

11gR1 = 11.1.1.x (e.g. 11.1.1.5.0)

11gR2 = 11.1.2.x (e.g. 11.1.2.1.0)

Thanks in advance for your comments and suggestions.  Let's get the JDev Extension community going in 2012!

--jb

John "JB" Brock
Oracle Product Manager - JDev ESDK



Thursday Aug 25, 2011

Adding Exteneral Libraries to an Extension in 11gR2

I mentioned this recently in a comment response, but it has come up enough times now, that it deserves it's own topic.


MANIFEST.MF

If this is a new project in 11gR2, you should already see a MANIFEST.MF file in your project in the same location as the extension.xml.

If you don't see it, add the file in the META-INF folder along with the extension.xml file.
Add the default 3 lines to the file of:
Manifest-Version: 1.0
Bundle-ClassPath: .
<blank line>

Adding an External Library

external:$ORACLE_HOME$/jdeveloper/mydir/mylib/myjar.jar

Using the default above, and this example line, the Bundle-ClassPath would look like.

Bundle-Classpath: ., external:$ORACLE_HOME$/jdeveloper/mydir/mylib/myjar.jar

You can verify that your external library is being added to the bundle by right-clicking on the project in the navigator panel, and selecting "Deploy To Target Platform".  In the Deployment tab of the Log window, click on the link to the deployed package and open the manifest.mf file to make sure everything is listed as you want it to.


If you find that the MANIFEST.MF is not being merged after you do the "Deploy to Target Platform", do the following to force the merge.

Go to project properties and click on the Deployment section. Select the "Extension" deployment profile and click on Edit.


Add the path to your new MANIFEST.MF file to the "Add additional manifest files..." section.


You usually do not need to do the step above, but I have had people tell me that the merge isn't happening for some reason, and this fixes it in those cases.

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 "http://jcp.org/jsr/198/extension-manifest"

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.

Conclusion

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 manifest.mf 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 manifest.mf 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.

Classpaths


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.

Trigger-hooks

 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.

Actions

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, " http://xmlns.oracle.com/jdeveloper/1013/extension  ".  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

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.


Gallery

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,
"http://xmlns.oracle.com/jdeveloper/1013/extension"

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:

<icon>${OracleIcons.LABEL}</icon>

 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="http://jcp.org/jsr/198/extension-manifest" "

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.

Conclusion...

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 manifest.mf 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.

More...

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!


Monday Jul 26, 2010

What's New in JDeveloper 11gR2 Extension Development

With the release of JDeveloper 11gR2, the entire Extension Framework has been reworked so that extensions are now implemented as OSGi modules. Extensions written for previous versions of JDeveloper will not work with this release until you do some modifications to your code.

What does this mean to extension developers?

Lazy Loading

The biggest impact is when and how an extension is loaded.  Jdeveloper use to load all extensions at the same time when JDeveloper was first started.  We now take advantage of something called Lazy Loading.  Extensions are only loaded when the developer needs them.  This allows JDeveloper to have a much faster startup time, and also a lower memory footprint while running since extensions that you don't need, are not loaded.

Trigger Hooks

With this release, there is the introduction of Trigger-Hooks in the extension.xml file.  This is separate from the older Hooks element.  Because an extension isn't loaded automatically by calling the Addin.initialize() method any longer, you need to add an action or event to the trigger-hooks section so the IDE knows when to load your extension.
You can take a look at the trigger-hooks wiki to see the existing trigger-hooks available in this release.

Separate Classloaders

With the use of OSGi, comes the use of a separate classloader for each extension.  You may have to change how your extension sets it's dependencies. The classpath element in extension.xml is no longer used. You set the dependencies in the Manfest.MF files instead.

Run and Debug from the IDE

There is an extra step now for running or debugging your extension from within the IDE.  Before you click on the Run Extension or Debug Extension options, you must click on "Deploy to Target Platform" first.  This rebuilds the Manifest.MF files with any changes to your project.  This will become a little smoother in a future release, but for now, you just have to do this one extra step.

JDeveloper Extension Development Guide

With such a significant change to the framework, we had to update the documentation to go with it of course.  A completely new Extension Developer Guide has been written for this release.  It's a great place to start.

What's next?

Those are the major changes for the Extension Framework in this release. They are quite significant.  I will be posting another entry shortly where I will walk through the steps of taking an existing extension project, and migrating it to work with the new OSGi enabled framework.  Stay tuned for more.

As always, please feel free to post any questions or personal experiences in the comments. I'm sure everyone's experiences with migrating existing extensions will be of benefit to all of us.




Monday Jul 12, 2010

It has to start somewhere...

[Read More]
About

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.


Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today