Practical Eclipse Plugin Development
Practical Eclipse Plugin Development
Dinis Cruz
Buy on Leanpub

Table of Contents

Leanpub book, originally based on Blog posts

This book contains the Eclipse related blog posts posted on Dinis Cruz’ blog at http://blog.diniscruz.com.

This is the first release of this book, so please send your suggestions, criticisms, ideas or comments to dinis.cruz@owasp.org

Notes about current structure

At the moment, the chapter order is the one created by the original ‘import from blogger’ (i.e. by publish order). A better idea might be to create logical groups, so that the posts are ordered based on some user-friendly criteria (still to be defined)

At the moment I’m working/thinking about the best way to structure this content, and how to present it in a easy to read/consume format.

It would be great if you (the reader) could provide some feedback on the book’s structure, for example:

  • if you think the book’s order should be different (or chapters renamed)
  • there is content missing (really important to cover in an Eclipse Plugin development book)
  • a particular chapter is not very clear, easy-to-understand or relevant
  • etc…

About the Author

Dinis Cruz is a Developer and Application Security Engineer focused on how to develop secure applications. A key drive is on ‘Automating Application Security Knowledge and Workflows’ which is the main concept behind the OWASP O2 Platform and the FluentSharp APIs.

After many years (and multiple roles) Dinis is still very active at OWASP, currently leading the OWASP O2 Platform project and helping out other projects and initiatives.

After failing to scale his own security knowledge, learned Git, created security vulnerabilities in code published to production servers, delivered training to developers, and building multiple CI (Continuous Integration) environments; Dinis had the epiphany that the key to application security is “Secure Continuous Delivery: Developer’s Immediate Connection to What They’re Creating”. This ‘Immediate Connection/Feedback’ concept is deep rooted in the development of the O2 Platform, and is something that will keep Dinis busy for many years.

Change log:

Here are the changes made (per version):

  • v0.40 (Jan 2016)
    • Added new local editor ui (from o2platform/leanpub-book-site repo) which provides an local preview of the book as a website
    • renamed all files and saved them with an .md extension (most were still in .txt format)
    • a local site (using express) to preview content
    • generation of Leanpub manuscript folder from a better formatted folder structure
    • Fixed tons of content formatting issues and broken images
    • removed chapters:
      • ‘High-Res images of TeamMentor’s Fortify integration in Eclipse’
      • ‘Eclipse Plugin that allows the execution of REPL Groovy Scripts (in the current Eclipse Instance) and Fluent API for Eclipse+SWT’
      • ‘Using AngularJS in Eclipse, Part 2) Add Some Control’
      • ‘Using AngularJS in Eclipse, Part 3) Wire up a Backend’
      • ‘Using AngularJS in Eclipse, Part 4) Create Components’
      • ‘Eclipse Groovy REPL - Open TeamMentor Article in multiple formats’
  • v0.16 (March 2014)
    • First release of book with raw import from blogger posts (no formatting or editing done)
    • Created Git repo on local dropbox sync folder
    • created github repository for this book: https://github.com/DinisCruz/Book_Practical_Eclipse
    • Added this change log
    • Added new Book cover

1. August 2013

  • Programming Eclipse in Real-Time (using an ‘Groovy based’ Eclipse Plug-in)

Programming Eclipse in Real-Time (using an ‘Groovy based’ Eclipse Plug-in)

While working on an Eclipse plugin to integrate TeamMentor with Fortify, it was driving me crazy to have to deal with the loop of:

  • Write the code in the main Eclipse instance (hosting the Eclipse plug-in project)
  • Start the Eclipse plug-in project (in debug mode)
  • Wait about 1 minute for the 2nd instance of Eclipse to start
  • See the changes
  • Make some fixes
    • If I’m luck they will be in a place that can be done (in the hosting Eclipse instance) without a restart of the 2nd eclipse
    • If I’m not lucky, go back to step one

This approach has a number of problems

  • Eclipse is quite an heavy and memory hungry application
  • The changes are not done in a REPL mode (i.e. interactive with immediate feedback to the execution result)
  • It is very hard to try existing Eclipse APIs and ‘see what they do and how they work’ (very important when learning a new API)
  • The Java APIs (just like the C# ones) are very verbose, ugly and hard to use (specially when compared with the type of coding I am now used to with FluentSharp APIs)

What I really wanted was the same environment that I created for .NET, where I was able to Program VisualStudio in real-time using C# REPL

I.e. I want to program Eclipse in real-time (i.e. the executed plug-in code must have access to the ‘current’ Eclipse application (i.e. its host)). This capability will be critical for one of my next stages of development, which will be based on having access to the artefacts currently available/exposed on other plug-ins (from java AST to other tool’s results)

I also wanted to move away from pure Java code and use something like the O2 Platform REPL Enviroment.

One option was to use Jni4Net (see Using Jni4Net (Part 3) - Writing and Invoking O2 Methods from Java and Eclipse), but after doing a bit of research I found Groovy which seemed like the perfect way to write Java code (and it is also very similar in philosophy to FluentSharp’s extensionMethods and capabilities).

As I tweeted at time, I was able to pull it off :)

Here is a Groovy script that changes the title of the current Eclipse application:

Here is a script that opens a WebBrowser in a particular Url:

Here is a (very rough/poc) script that dynamically adds a number of buttons to an existing SashForm:

… the code shown above, when executed, looks will do this (note the extra buttons):

How it works

As with the O2 .NET VisualStudio extension, my objective was to create the smallest possible Eclipse Plug-in that only did one thing: expose an REPL Script environment.

The idea is that once there is a REPL environment, the rest can be programmed+compiled+executed dynamically (i.e. only the original plug-in code would be written in Java, and have a hard dependency on eclipse (i.e. a place where changes require a restart (and making a cup of tea)).

What follows is the description of the multiple files and techniques used to achieve the REPL environment shown above.

The eclipse plug-in created was based on the MultiPartPageEditor sample.

Here is the current project structure:

The_ plugins.xml_ file defines an: editor, view, wizard:

… and menu:

The MANIFEST.MF files looks like this

In an Eclipse plugin (as far as I can tell), the execution starts with the class defined in the Bundle-Activator setting (highlighted above).

In this case that is the g2.scripts.Activator, which looks like this:

Note that this file doesn’t do nothing fancy.

In this first version of the plugin, I reused the auto created (from the sample code) Wizard:

… with only a small change made on the default editor contents:

The SampleNewWizardPage.java, is also just about the same as the original version, with only a small change on the file extension.

Here:

… here:

… and here:

To see this wizard in action, start the plug-in, and (after waiting for the new Eclipse instance to start), and select File –> New – > Other:

… on the G2 Wizard category, select the Write G2 Script option and click next

In the next chose a container (i.e. where the new file will be created)

… click finish:

… and we will have an REPL environment that looks like this:

*Running Groovy scripts (REPL Style)**

In the environment shown above, if we click on the Compile and execute code button, we will see the execution result in the purple panel (which in this case is the global answer to everything: 42)

Since this is a Groovy environment, we can write and execute any valid Goovy commands. For example:

… same output using Goovy’s equivalent of C# Lamda methods:

Here is a simple script to get all methods available in the String class:

.. similar output in one line of code (isn’t Groovy great?):

OK, so what is happening under the scenes?

In the 2nd Eclipse, when a *.g2 file is opened, an instance of the MultiPageEditor will be created.

Back into the original/host Eclipse, the main changes on the MultiPageEditor.class file are the use of the MyEditor class:

… on the page0 (first tab):

It is on the MyEditor class that all the Goovy REPL functionality was implemented:

The MyEditor class extends the GroovyEditor with a number of extra variables that will be made available to the Groovy script:

The G2 editor GUI is created on createPartControl method which will:

  • Create a SashForm and assign it to the provided parent
  • Add a Button with a callback to compileAndExecuteCode method
  • Add a StyledText and make it purple (this will be used to show the execution result)
  • Set a number of variables (based on the currently available objects)

The compileAndExecuteCode method is used to execute the compileAndExecuteCode_InGuiThread in the current UI thread (so that any uses of UI objects don’t throw ‘thread access exceptions’):

The compileAndExecuteCode_InGuiThread will:

  • Get the current text from the TextEditor
  • Create a Binding object and assign a number of very interesting/powerful objects to it:
    • shell: the actual main Eclipse UI shell object (for example its text field is the title of Eclipse)
    • composite: main/host panel for the current Editor
    • **editor: **the current editor object
    • workbench: **Eclipse Workbench object (same as calling **PlatformUI.getWorkbench() from code)
    • Display: the UI Display objet
    • testGroovy: an Goovy class (more details bellow
  • Create a GroovyShell object that uses the current plug-in ClassLoader (which means that we will have access (from the groovy scripts) to all the currently loaded plug-in jars/classes)
  • Execute/eval the text we got from the TextEditor
  • Set the output panel with the result (or any compilation/execution errors)

In practice this setup means that we can write scripts using the objects set in the Binding object, for example the shell object:

Another really cool feature/capability, is that it is also possible to have a native groovy class:

… created from Java:

… added to the Groovy’s Binding object:

… and accessed by the real-time Groovy execution environment:

Here are the default values of the TestGroovy class:

… which can be changed and viewed like this:

This last part is REALLY interesting/powerful, since it means that we can develop an groovy based API in real-time (2nd Eclipse instance), which is then added to the host eclipse instance (i.e. the plugin-code)

Btw: I’m pretty sure there are easier ways to do this, and it would be great if I could get some help with the next versions (for example I had probs using the GroovyEditor outside an Eclipse Editor/Page environment and I was not sure how to enable CodeComplete/Intelisense to the GooryEditor)

Deployment

To deploy this I created an Feature and UpdateSite project (which once the plug-in is a bit more mature, I will find a location to host it in a public environment)

This is just the beginning….

Eclipse coding here we go….

2. September 2013

  • Opening up a native Chrome Browser window inside Eclipse (raw version)
  • Injecting HP Fortify Eclipse Plug-in Views into HP’s WebInspect UI

Opening up a native Chrome Browser window inside Eclipse (raw version)

On the Win32 Window’s Hijack theme, here is a raw version of how to show an actual Chrome browser window inside an Eclipse view (ie. a window from a C++ process inside a JVM-based Process).

Using the Groovy execution capabilities described in the Programming Eclipse in Real-Time (using an ‘Groovy based’ Eclipse Plug-in) post, in Eclipse, I start by creating an instance of a SWT panel and get its handle:

After executing that script we will get an empty panel in the bottom of the screen:

… and the 4461984 return value in the purple ‘Groovy script output window’

… which is the handle to that Panel/View (which is where were we are going to insert our hijacked window).

In an C# REPL UI, we can now use this script (that consumes that 4461984 handle) to open an Cmd.exe and hijack its window into the Eclipse panel:

… which looks like this:

… in eclipse:

Since what we want is chrome, we can use the API_Chrome_Hijack API to:

  1. open up a new instance of chrome,
  2. find its dedicated process and
  3. get that process MainWindowHandle

… which looks like this:

Finally here is the script that starts a new instance of chrome and insert’s it into the eclipse panel:

… which looks like this (in Eclipse)

Note the native Chrome window (C++ Process) fitting nicely with the Eclipse UI (JVM Process)

Since chrome is now running inside an native Eclipse view/control, we can put it where ever we want tit to be (inside the Eclipse UI).

Like on the top right:

… on the left:

… maximised

… as a detached eclipse window:

..or in the middle (with another chrome tab opened inside the same Hijacked panel)

Here is the Groovy script that created the panel (in Eclipse)

1 def panelView = activePage.showView("g2.scripts.views.DefaultPart_Panel");  
2 return panelView.panel.handle;

Here is the C# Script that did the Handle setParent:

 1 var chromeHijack = new API_Chrome_Hijack().open_ChromeDriver();  
 2 var chromeHandle = chromeHijack.ChromeProcess.MainWindowHandle;
 3 
 4 var eclipsePanel = 4461984.intPtr();
 5 
 6 chromeHandle.setParent(eclipsePanel);
 7 
 8 500.sleep();
 9 
10 chromeHandle.window_Maximized();
11 
12 //O2File:API_Chrome_Hijack.cs  
13 //O2File:API_WinAPI.cs  
14 //using O2.XRules.Database.APIs

Injecting HP Fortify Eclipse Plug-in Views into HP’s WebInspect UI

Using the O2’s Win32 Window Hijacking capabilities (see also Opening up a native Chrome Browser window inside Eclipse (raw version)) , here is a PoC on how to inject a couple Eclipse Views from the HP Fortify Eclipse plug-in (which is Java app running under an JVM) into the HP WebInspect UI (which is .NET app running under an CLR).

The power of this PoC is to show that we can have the best of both worlds and show security consultants and developers the best possible environment/UI for them to analyze, review and fix security vulnerabilities.

We start with an instance of Eclipse Juno with the Fortify Plug-in installed, where I opened the Fortify Audit perspective, in order to have access to the multiple Fortify specific views:

Next I opened an instance of WebInspect 10.0:

Since we need to add a couple panels into WebInspect (which is a .NET process), the first step is to inject an O2 REPL UI into the WebInspect process.

Note 1: if we were doing a pure Win32 Handle Hijacking this would not be needed, but in this case I want to control where the Fortify Views will be placed.

Note 2: since Web Inspect is running with elevated privileges (i.e. full admin), we will also need to run the O2 Platform with the same privileges (or the dll injection will not work).

The script/tool that I’m going to use is the Util - Inject O2 into other processes.h2, which can be executed from here:

…or here:

On the Util - Inject O2 into other processes.h2 UI, find the WebInspect process on the left-hand-side process list (a screenshot of the process should be visible if we have enough privileges to inject into this process) and click on the ‘Inject O2 REPL into Process’ button:

An C# REPL Editor should appear (a good clue that the injection worked ok is the fact that the top-left icon of the the REPL Form matches the icon of WebInspect):

Another way to confirm that this C# REPL script is indeed inside the WebInspect process, is to execute:

1 return Processes.getCurrentProcess();

… which will return the C# object of the current process (note the ProcessName value below):

Since WebInspect is using .NET WinForms as its main windows host (there are a number of WPF controls in there, but the main window is an instance of System.Windows.Forms.Form), we can use this command to get the list of open forms:

1 var openForms = Application.OpenForms;  
2 return openForms;

Which in this case returns 3 Form Controls:

  • the main WebInspect UI
  • an hidden WebInspect update window
  • the O2 platform C# REPL (currently executing the script)

Next, using this script: 

1 var form = (Form)Application.OpenForms[1];  
2 return form;

… we find the Form we want:

… which is of type SPI.WebInspect.MainForm:

…from the WebInspect.exe assembly:

… which means that we can get a strongly type reference to that control:

… after adding a reference to the SPI.UI.dll (as requested by the error shown above):

What is really powerful about this script: 

1 var form = (MainForm)Application.OpenForms[1];  
2 return form;
3 
4 //using SPI.WebInspect  
5 //O2Ref:WebInspect.exe  
6 //O2Ref:SPI.UI.dll

… is that the .NET object shown in the output window, is the real WebInspect main Form object (see below how I changed the title of the main WebInspect window (from the PropertyGrid shown in the C# REPL output panel)):

Next (because we can) we are going to inject this script environment right into WebInspect UI, using the script: 

1 var form = (MainForm)Application.OpenForms[1];  
2 form.insert_Right()  
3     .add_Script_Me(form);  
4 return form;
5 
6 //using SPI.WebInspect  
7 //O2Ref:WebInspect.exe  
8 //O2Ref:SPI.UI.dll

This will create a new Panel to the right of the current main UI and add a C# REPL Script UI to it (with the WebInspect UI form variable passed as a parameter):

Using the C# REPL that is now inside the main WebInspect UI, let’s create another panel (now to the left) and get its handle (which in this case it is going to be 592370) 

1 var fortifyPanel = mainForm.insert_Left();  
2 return fortifyPanel.handle().str();
3 
4 //O2Ref:WebInspect.exe  
5 //O2Ref:SPI.UI.dll

The 592370 handle is what we need to in order to be able to inject Windows into that left hand side panel (basically we will set the parent of the ‘Window to Hijack’ to 592370).

For example if we wanted to add a real cmd.exe command prompt to it we could execute:

1 var leftPanelHandle = 592370.intPtr();
2 
3 var cmdExe_WindowHandle = "cmd.exe".startProcess()  
4                                    .waitFor_MainWindowHandle()  
5                                    .MainWindowHandle;
6 
7 cmdExe_WindowHandle.setParent(leftPanelHandle);
8 
9 return cmdExe_WindowHandle.str();

… which will look like this

.. note that this is the full cmd.exe (which can be resized, moved and used to execute commands):

… or even maximized:

… we can even add other processes to it, like Notepad, using the script 

1 var leftPanelHandle = 592370.intPtr();
2 
3 var cmdExe_WindowHandle = "notepad.exe".startProcess()  
4                                        .waitFor_MainWindowHandle()  
5                                        .MainWindowHandle;
6 
7 cmdExe_WindowHandle.setParent(leftPanelHandle);  
8 return cmdExe_WindowHandle.str();

… which will look like this:

The examples above used the main process window (whose parent was originally the handle 0 (i.e. the Desktop)).

But we can do the same thing for any child window.

For example we could inject the actual Notepad Text Editor (vs the whole Notepad UI).

The following script:

 1 var leftPanelHandle = 592370.intPtr();
 2 
 3 var notepadProcess = "notepad.exe".startProcess();  
 4 var notepad_WindowHandle = notepadProcess.waitFor_MainWindowHandle()  
 5                                          .MainWindowHandle;
 6 
 7 var notepadInnerWindow = notepad_WindowHandle.child_Windows().first();
 8 
 9 10000.wait();
10 
11 var originalParent = notepadInnerWindow.get_Parent();
12 
13 notepadInnerWindow.setParent(leftPanelHandle);  
14 notepadInnerWindow.window_Redraw();
15 
16 10000.wait();
17 
18 notepadInnerWindow.setParent(originalParent);  
19 return notepadInnerWindow.str();

Will:

  1. Open Notepad
  2. Get Notepad’s main window handle
  3. Get the first child window from that handle
  4. Save the parent of the first child window
  5. Wait 10 secs (to give us time to type something on the Notepad window, when running OUTSIDE the WebInspect UI
  6. Set the parent of the Notepad child window (the TextEditor) to be the Webinspect Panel
  7. Wait 10 sec (to give us time to type something on the Notepad window, when running INSIDE the the WebInspect UI)
  8. Reset the original Notepad Child window parent

Here is what it look like before step #8 executes:

OK, so now that we have the ability to inject any window into WebInspect, let’s add something interesting like a view from Fortify’s Eclipse Plug-in (which is a Java app).

To do that we need to find the handle of the window we want to inject.

There are numerous ways to do this, one of them is to use the Util - Windows Handles - View Handle Screenshot.h2 script:

… which can be easily used to:

… find the handle we want (note the red box highlighting the selected window (also shown as a screenshot inside the Util - Windows Handles - View Handle Screenshot.h2 script UI))

Once we know the handle of the window we want to inject (in this case 794042), we can automate the injection using this script: 

 1 var leftPanelHandle = 592370.intPtr();  
 2 var fortifyPanel    = 794042.intPtr();  
 3 //return fortifyPanel.get_Parent().str(); //400746 (backup in case we want to restore it)
 4 
 5 fortifyPanel.setParent(leftPanelHandle);
 6 
 7 return "done";
 8 
 9 //using O2.XRules.Database.APIs  
10 //O2File:O2File:API_WinAPI.cs

… which will create this:

Note 1: the Fortify Eclipse Plugin panel (top-left) is now in WebInspect and not in Eclipse

In the screenshot above the Fortify Plug-in View was not correctly resized to its new parent. This can be corrected using this script:

1 var leftPanelHandle = 592370.intPtr();  
2 var fortifyPanel    = 794042.intPtr();
3 
4 var rect = fortifyPanel.get_Parent().window_Rectangle();
5 
6 fortifyPanel.window_Move(0,0,rect.Width,rect.Height);

… which will set the size of the injected window to be the size of its parent (another option would had been to call the .window_Maximize() extension method):

Returning back the Fortify Eclipse Plugin View

Here are a couple interesting places to put the view back:

Example #1) The Desktop** (using the parent handle 0)

Note that that window will not be movable or resizable (i.e. it is stuck in that location))

Example #2) Cmd.exe (using the cmd.exe MainWindowHandle as the parent)

Note that in cases like this, the host process can be resized but the injected window will remain in the same relative place (to its parent window)

So we can create GUIs like this, where the Fortify Plugin View is nicely positioned to the top right of a cmd.exe process:

Example #3) Notepad: (same technique as shown above)

Example #4) Eclipse** (returning the view to its original parent)

3. November 2013

  • SI Open Sources the Eclipse Plugin-development toolkit that I developed for TeamMentor
  • TeamMentor Plugin and Builder v1.5.6 (Source Code and Eclipse Update site)

SI Open Sources the Eclipse Plugin-development toolkit that I developed for TeamMentor

For the past couple months I have been working on a Eclipse plug-in for TeamMentor (see Programming Eclipse in Real-Time (using an ‘Groovy based’ Eclipse Plug-in) , Opening up a native Chrome Browser window inside Eclipse (raw version) , Injecting HP Fortify Eclipse Plug-in Views into HP’s WebInspect UI and Two Videos showing TeamMentor Eclipse Plugin integration with Fortify Eclipse Plugin (as shown in HP Protect 2013 conference) ).

I had a number of culture chocks coming from a C#/VisualStudio/O2Platform/REPL world into a Java/Eclipse one. The biggest one by far was the loss of ‘semi-real-time’ code execution that I have in Windows/C#. I used the O2 Platform REPL (and Resharper+Ncrunch VS plugins) to have a proper TDD development mode (i.e. high effectiveness and productivity), and in the Eclipse world (specially in plugin development) I had a 10 to 30 sec delay before seeing the result of any code or UnitTests execution! (which is 95% slower than what I was used to)

So, as I guess it is typical of me, I didn’t just create an Eclipse Plugin. I created an ‘Eclipse Plugin to create/develop Eclipse Plugins’** (think of it as a ‘Groovy based Eclipse Plugin where the Groovy scripts have access to the Eclipse Objects of the Eclipse instance running those Groovy scripts’ :) )

Which is basically an evolution of what you see at: Programming Eclipse in Real-Time (using an ‘Groovy based’ Eclipse Plug-in)

Now the great news is that SI (Security Innovation) as agreed last week (during AppSec USA) to open source the ‘Eclipse Plugin Builder kit’ part of the ‘TeamMentor Eclipse Fortify Plugin’. Which is great news since it will allow for this technology and technique to be used for a much wider audience, and maybe even to be part of the Eclipse/Groovy codebase one day.

It also has lots of good benefits for SI, which is of course a for-profit company and needs to base its decisions on solid commercial decisions. As you can see below (in the email I wrote to SI) there are lots of synergetic benefits for SI to open source the ‘Eclipse Plugin Builder kit’ (i.e. this is a good example of when the community needs and business needs are aligned, and we have a win-win scenario).

There will be an official announcement over the next couple weeks, the code will be more cleaned up, and documentation will be written.

Meanwhile, and just for record, here is how it happen (so that others can see how ‘easy’ it is to open source apps developed internally)

Step 1) have the code already in GitHub

See https://github.com/TeamMentor/TeamMentor_Eclipse_Plugin

Step 2) make the business case internally and get a YES

Here is the email I sent internally which lead to the ‘ok do it’ answer

Greetings from AppSec USA

I know there has been a number of threads on this, and I think the time is right to wrap this up.

In a nutshell the current TeamMentor Plug architecture is one where:

  • 95% of the code is on a ‘Eclipse Plugin Build Kit’
  • 5% of the code is on the ‘Fortify specific integration’

I.e. when the plugin starts there is nothing ‘Fortify specific to it’ . It is only after Eclipse loads up that the ‘Fortify specific bits’ occur

So what I’m talking here is to Open Source ONLY that ‘Build Kit’ and keep the Fortify bit private, and actually SELL and Distribute the ‘specific TM integration with products like Fortify’.

I think this is the best of both words specially since it would still allows us to:

  • be able to charge for any plugin we develop, e.g., Fortify, Checkmarx
  • do not give away TM content for free
  • enable 3rd-parties to develop a TM plugin w/o our engineering resources, e.g., Parasoft, Coverity, Klocwork

I can argue that the benefits are even greater (think about developers having an ‘TeamMentor’ tab on their Eclipse dev environment), but I wanted to cover the areas of concern.

Now the only caveat is that we have an opportunity today to launch this at AppSecUSA to a really great audience.

Today I’m doing an O2 Platform presentation from 10am to 11:45am and that would be the perfect place to ‘announce this’

So if we can reach the agreement to open source the ‘Eclipse Plugin Build Kit’ today, I can already announce it and talk about it with a number of target companies that would want to use it: e.g., Parasoft, Coverity, Klocwork, WhiteHat , etc..

I’m around to talk if you want :)

Dinis

To put this into context are a couple important points:

  • Although there had been multiple talks internally before on the ‘business model of the plugin’ there was no firm decision about it
  • There were already a number of key SI player on both camps (the ‘lets open source it’ and ‘lets sell it’)
  • Key in making this happening was to make sure that the concerts of the ‘lets sell it’ where addressed directly
    • Basically it is critical that such decision is based on solid business decisions and what is good for SI
    • Remember that SI has been paying me to write the code that has now been open sourced, which in effect means that SI has been paying for the development of Open Source software
  • I didn’t plan to ‘push’ such decision at AppSec, it just happened and I just had a felling/instinct that that was the right moment to do it
  • SI is a very unique company where ideas are given a fair chance of success, and this is another good example of it

Step 3) Once the YES is obtained, make it public as soon as possible

In my case I was able to talk about it at the O2 Platform presentation I was giving (with already a number of attendees interested in helping) and start informal conversions with 3rd party companies that were at AppSec about their use of the ‘Plugin Development kit’ to create/extend Eclipse Plugins for their products.

Note that at this time I hadn’t actually changed the license (which I have now done), but I believe that in this industry trust is an asset, and that reverting such decision would be a lose-lose situation for everybody involved.

Step 4) Changing the license and Opening up the code (make the repo public)

To make it ‘official’ all I did was to add the license.md file (screenshot below) to the https://github.com/TeamMentor/TeamMentor_Eclipse_Plugin and https://github.com/TeamMentor/TeamMentor_Eclipse_Plugin_Build repositories:

Note that although this will be cleaned up in the coming weeks/months, this file (on an open repo) makes it official and pass the ‘point of no return’.

This is what I mean to individuals/companies when I say that they should_ ‘Open source sooner rather than later, and just do it!’. Since all it takes (to kickstart it) is to add a license file and open up the repo (in this case the repo was already open).

And guess what happens after such move, NOT MUCH, so if you are in a similar situation (you know who you are), JUST DO IT!

Note this is one of those moves that has to happen, since what the process of making it open really does, is that allows for people/companies that would like the be involved, to finally start thinking about how/where/where they should do it (i.e. the sooner this process starts the sooner something real can actually happen).

Step 5) Build community, document and officially release it

Which is what is coming next, so if you want to help, please join the party and lets dramatically simplify the process/effort of creating Eclipse plugins :)

I would love to see tons of forks and usage of this Eclipse Builder Kit, specially since this now brings the O2 Platform REPL environment to Eclipse, which means Java, which means OSX and Linux :)

TeamMentor Plugin and Builder v1.5.6 (Source Code and Eclipse Update site)

TLDR: open eclipse and install the plugin from: http://eclipse-plugin-builder.azurewebsites.net

I just updated the TeamMentor_Eclipse_Plugin repo with the latest version of this plugin (take a look at the develop branch which is in sync with the develop branch in my dev fork).

This code is now Open Source (see SI Open Sources the Eclipse Plugin-development toolkit that I developed for TeamMentor) so fell free to take a look, fork it and figure out how to use it.

Note that we are in active development of this plugin, with still a number of bugs/issues to address before the first official release.

The final version of this plugin will not have the Fortify Groovy script/extension, since that will be changed into a separate project and install (at the moment if you run the current version of the plug-in in an instance of Eclipse with the Fortify plug-in installed, you will see TeamMentor guidance showing up every-time you click on a finding in the Fortify View).

The deployment files (ie eclipse installs) are all stored in the TeamMentor_Eclipse_Plugin_Deploy repository which you can clone and use as an eclipse plugin installation folder.

But the easiest way to start using it is to use the http://eclipse-plugin-builder.azurewebsites.net update site (which contains a push of TeamMentor_Eclipse_Plugin_Deploy).

Over the next couple days, I’m due to write a number of technical blog posts and documentation about this plugin, so watch this space.

Finally, if you have specific areas of the ‘Eclipse Plugin Builder’ architecture that you want me to focus on, please let me know and I will try to cover it.

4. December 2013

  • Installing Eclipse Plugin Builder, accessing Eclipse objects and adding a new Menu Item that opens Owasp.org website
  • How to word-wrap a word without breaking it (when using bootstrap)
  • Installing, compiling and failing to use DCE VM for Eclipse Plugin development
  • Using JRebel to HotSwap new Static String fields in an Eclipse Plugin (without Eclipse restart)
  • Adding and using new API methods, that are consumed by an Eclipse Plugin under development (without Eclipse restart)
  • Groovy Script to create a view that shows the images available in the ISharedImages class
  • Executing Eclipse Plugin JUnit tests in real-time without needing to restart Eclipse (with no mocking)
  • XStream “Remote Code Execution” exploit on code from “Standard way to serialize and deserialize Objects with XStream” article
  • How to create (using Eclipse) JavaDocs that looks good? (My current approach is not working)

Installing Eclipse Plugin Builder, accessing Eclipse objects and adding a new Menu Item that opens Owasp.org website

This post shows how to use the Eclipse Plugin Update site described in TeamMentor Plugin and Builder v1.5.6 (Source Code and Eclipse Update site) to install and use the Eclipse Builder Kit that we open sourced last week.

The objective is to do these actions, without needing to start Eclipse to see them:

  • Dynamically access eclipse objects like: Shell, Workbench, Worksapce, ActiveWorkbenchPage, Display, etc…
  • Open the http://www.owasp.org website in a browser (and put it inside an Action object)
  • Add new Menu called ‘OWASP’
  • Add a menu Item to the ‘OWASP’ menu called ‘Open OWASP website’ that calls the Action object that opens wht OWASP website.

Step 1:_ _Install the TeamMentor Plugin version 1.5.6 in Kepler

In a default install of Kepler (this should also work in versions 3.7 (Indigo) and 4.2 (Juno))

…open the Install New Software… menu option:

…enter the value http://eclipse-plugin-builder.azurewebsites.net the Work with: Textbox

…select the TeamMentor Eclipse PlugIn – For Fortify option and click Next

… click Next:

… accept the terms and click Finish:

… click OK on the unsigned warning (this will be addressed on the final build)

… and finally click Yes to reboot:

Step 2: Enable script support and write a ‘Hello World’ script

Once Eclipse starts, you should see a TeamMentor menu, where you need to click on the Open Properties Page menu item

… select the Show Advanced Mode Features checkbox:

… click OK

… and open the Util – Write Script (TeamMentor DSL) menu item from the (new) Advanced and Debug Features menu

NOTE: if you are running this on Indigo, you will need to restart Eclipse since menu visibility is not loaded dynamically (as it is in Kepler). I’m sure there is a way to force its refresh, so if you know about it, let me know.

The scripting UI should look like this:

… where if you click on Execute you should see of one of TeamMentor’s article showing up in a browser window

… and an eclipse object string representation (in this case tm.eclipse.api.EclipseAPI@1ffbe29) in the script UI’s Execution result panel

To create the first Hello World example, replace the text inside the Groovy Code panel with:

… and click on Execute to see the Hello World in the Execution result panel

Note that the Execution result will show the last object of the Groovy script execution, so you can just do this:

Step 3: Access Internal Eclipse objects to view/change properties values and invoke methods

What is really powerful about this scripting environment, is the fact that it is running on the Eclipse JVM, which means that it has access to all Eclipse objects in real time.

In practice, this means that we can access Eclipse objects and manipulate them right inside the Eclipse instance we are running the scripts! No more waiting 30s to see the effect of a code change or simple code test :)

To make life/coding easier, most of the common objects one needs when programming eclipse are exposed via the EclipseApi class, which is available via the eclipse object (or the eclipseAPI object) already mapped to the current Groovy script being executed:

Groovy has a nice Object Viewer helper UI in the groovy.inspect.swingui.ObjectBrowser class, which is exposed as the inspect({any object}) method that can be used (see below) to view all Public Fields and Properties of the eclipse object:

and all (Meta) Methods:

Here is a quick view of the main helper fields mapped to Eclipse objects:

eclipse.shell

…. which is an instance of org.eclipse.swt.widgets.Shell:

eclipse.workbench (instance of org.eclipse.ui.internal.Workbench)

eclipse.workspace (instance of org.eclipse.ui.internal.resources.Workspace)

eclipse.activeWorkbenchPage (instance of org.eclipse.ui.internal.WorkbenchPage)

eclipse.activeWorkbenchWindow (instance of org.eclipse.ui.internal.WorkbenchWindow)

eclipse.display (instance of org.eclipse.swt.widgets.Display)

The reason why is very powerful to have access to these objects is that have real-time read/write access to its properties/fields

For example use inspect(eclipse.shell) to see the current Eclipse’s Shell object properties/fields:

note: since we are using Groovy we can also use: eclipse.shell.dump()

If you look at the list of the properties/fields in the eclipse.shell object, notice that there is one called text,which is the value of the current Shell window title (in the case below ‘Java – Eclipse’)

Not only we have access to this value, we can be dynamically change it:

We can also easily open views like this:

.. or get a list of open views:

Step 4: Add a new Menu Item that opens OWASP.org website

Now, lets say that we want to so something more interesting like adding a new Menu Item that opened the http://www.owasp.org website.

We can start with this code snippet that will open the Eclipse internal browser: 

1 def browserId = "Test Browser";  
2 def website= "http://www.owasp.org";  
3 def browser = eclipse.workbench.getBrowserSupport().createBrowser(browserId);  
4 browser.openURL(new URL(website));

… which when executed will look like this:

Next lets move the code that opens a browser into an Action object:

 1 import org.eclipse.jface.action.Action;  
 2 def final _eclipse = eclipse;  
 3 Action action = new Action()  {  
 4                                  @Override  
 5                                  public void run() {                              
 6                                                       def browserId = "Test Browser";  
 7                                                       def website= "https://www.google.com"; //"http://www.owa\
 8 sp.org";    
 9                                                       def browser = _eclipse.workbench.getBrowserSupport().cre\
10 ateBrowser(browserId);  
11                                                       browser.openURL(new URL(website));  
12                                                    }  
13                              }
14 
15 return action.run();

Here is the code that will create a new Menu (not visible until it has an action)

1 def menuName = "New Menu";  
2 def topMenuManager      = eclipse.activeWorkbenchWindow.getMenuManager()  
3 MenuManager newMenu = new MenuManager(menuName);  
4 topMenuManager.prependToGroup(IWorkbenchActionConstants.MB_ADDITIONS, newMenu);

Putting the two together:

 1 import org.eclipse.jface.action.*;  
 2 import org.eclipse.ui.IWorkbenchActionConstants;
 3 
 4 def final _eclipse = eclipse;
 5 
 6 def menuName = "New Menu";  
 7 def actionName = "open owasp.org";  
 8 def topMenuManager = eclipse.activeWorkbenchWindow.getMenuManager()  
 9 MenuManager newMenu = new MenuManager(menuName);  
10 topMenuManager.prependToGroup(IWorkbenchActionConstants.MB_ADDITIONS, newMenu);
11 
12 Action action = new Action(actionName) {  
13   @Override   
14   public void run() {   
15     def browserId = "Test Browser";  
16     def website= "http://www.owasp.org";  
17     def browser = _eclipse.workbench.getBrowserSupport().createBrowser(browserId);  
18     browser.openURL(new URL(website));  
19   }  
20 }
21 
22 
23 newMenu.add(action)
24 
25 topMenuManager.update(true);
26 
27 return topMenuManager;

We get a new menu:

…which when selected will open an browser with https://www.owasp.org

What is really interesting in the code sample above, is how close we are to programming in pure java in normal Eclipse plugin development mode (great when learning how the API works and following the existing code sample).

But since my view in API development is to make it as easy as possible to perform the desired action, I added an helper method to the EClipseAPI to create a menu item that opens a browser window

Using the helper API, the entire code above can be replaced with: 

1 def testMenu = eclipse.menus.add_Menu("Test Menu")  
2 eclipse.menus.add_MenuItem_OpenWebPage(testMenu, "Open OWASP website", [https://www.owasp.org](https://www.owa\
3 sp.org/))

…which when executed will add the Test Menu to the top menu with a Open OWASP website menu item

Note1 : In C# I could had made that API even simpler since I could had used Extension methods to add the add_Menu_Item method to the MenuManager class

Note 2: There are a couple more helper methods which you can see at: https://github.com/TeamMentor/TeamMentor_Eclipse_Plugin/blob/develop/TeamMentor.Eclipse.PlugIn.Fortify/src/tm/eclipse/api/Menus.java

Appendix: Auto updates

Once you can have the Plug-in installed, you can get updates via the ‘Check for Updates’ menu option (note that moment fixes are pushed as minor updates, so you might not get the latest version after the first install):

If there is an update, you will get a window that looks like this:

… where you can review the updates and click ‘‘Next’

… access the license and click Finish

… click OK (if you are not in an hostile network that is able to dynamically backdoor Eclipse plugins on the fly):

… and finally click YES to reboot:

Note: if you want the checks to happen automatically, you can set it here:

How to word-wrap a word without breaking it (when using bootstrap)

I just had one of those bugs that should had taken 5m, but ended up taking a lot more because the behaviour of HTML and bootstrap was not as easy as I was expected.

Basically the problem was that we needed to handle (in the TeamMentor Eclipse Fortify Plugin) the cases when we don’t have a TeamMentor mapping for the issue currently being shown in the Fortify views.

The solution was to show the current Fortify recommendation, which is available from their plugin (I need to explain how I got that data in another post), and after integrating that data in our plugin, it looked like this:

The problem is that (if you pay close attention) the word-wrap is actually breaking the words (which is not a good thing)

After much digging into Html, Google and Stack Exchange, I finally found a solution that seems to work ok.

Using the HTML style: word-break: normal; like this (so that I overwrite the bootstrap defaults):

1    "_**<pre style='word-break: normal;'>" + fortifyDescription + "</pre>"**_

With that fix in place, the view now looks like this:

Note: You can read all details about this bug here: https://github.com/TeamMentor/Master/issues/672

Although it was painful to find the root cause, due the to the real-time scripting (and development) environment that I now have in Eclipse I was able to experiment the multiple word-wrap options directly in the ‘real eclipse’ (the one that also has the Fortify plugin installed).

Here is what that dev/qa environment looked like:

With:

  • The Fortify SCA view on the left (which when clicked should trigger a TeamMentor view on the right)
  • The TeamMentor+Fortify Groovy plugin code in the middle, which is being executed on the current instance (i.e. code changes are immediate)
  • The TeamMentor view on the right which gave me a visual clue that the word-wrapping was working ok (btw, how can we Unit Test this issue? since the prob is only visible to the human eye (or maybe to an OCR-based script?))

To see this action, here is an example where a ‘script change’, after execution, is immediately shown on the right (without needing Eclipse restart)

Installing, compiling and failing to use DCE VM for Eclipse Plugin development

Last night I tried to use the amazing DCE VM tool (DCE = Dynamic Code Evolution) to apply hot fixes to the APIs I was creating for the open source Eclipse API Tool Kit I’m working on (as part of the TeamMentor Eclipse Fortify Plugin).

I was trying to address the limitations of the JVM’s HotSwap technology which only works on certain inline code changes, and doesn’t support at all the addition and changing of new methods.

TLDR: this post doesn’t have the solution for this problem (see next post which shows JRebel in action).

In this post I’m going to show the workflow/steps that I followed to:

  • create a version of DCE VM that worked on OSX Mavericks (after failing to use the provided binaries, and needing to compile the DCE VM code),
  • run eclipse under the modified/patched JDK
  • get a ‘hang’ in Eclipse when one of the dynamic code changes was applied.

Part 1: Trying to install the binaries

The first step was to go to the DCE VM website:

Open the Binaries page, download the osx version of dcevm-0.2-mac.jar and execute it locally:

Unfortunately there were no VMs picked up by default.

So I tried to the the default OSx Java install dir, which was here:

But that didn’t work:

So I downloaded from Oracle the latest version of the OSX JDK to this dev laptop:

… which was placed here:

But that folder didn’t work either

So didn’t this one:

But this did:

Well, it was originally recognized as a JDK, but when I clicked on Install

I got this error:

Part 2: Building DCE VM from Source

Since the binaries option didn’t work, it was time for plan B, which was to use the latest version of the code (from GitHub) and build it.

The best instructions I found came from this blog entry from Sogety: TRUE HOT SWAP IN JAVA WITH DCEVM ON OS-X :

… which took me though the following steps (you can copy and paste the instructions from that blog post)

After installing Gradle and the OSX dev tools, I cloned the https://github.com/Guidewire/DCEVM repo and switched into the full-jdk7u45 branch

Then I executed gradle

…. which took a while (with tons and tons of warning messages)

… and eventually:

… the compilation completed:

… the final step was to create a copy of the **jdk1.7.0_45.jdk _** folder and copy the created *.dylib files into the new _jdk1.7.0_45_dcevm.jdk/Contents/Home/jre/lib/server folder:

Finally I was able to try it, and I got this error (while executing java –version (as mentioned on the blog post)

… which was caused by the fact that the comment that works is java -version :)

So as you can see from the screenshot above, we now have a patched JVM with Dynamic Code Evolution enabled :)

Step 3) trying to use the patch JVM to run the TeamMentor Eclipse Plugin

Since there are a number of blog posts out there that show that once you have the patched JVM it should work (see Dynamic Code Evolution for Java, Redeploy alternatives to JRebel and Get True Hot Swap in Java with DCEVM and IntelliJ IDEA ), it was time to see it in action :)

I opened up the Eclipse which has the dev version of the plugin, went into the Run Configurations page, and created a duplicate of my main Eclipse Application configuration:

Then, on the_ Java Runtime Environment** section, I clicked on the **_Environments button:

Where I had to add the patched 1.7 JDK by clicking on Add…

Then choosing Standard VM on Add JRE popup window:

… selected this folder (note the_ jdk1.7.0_45_dcevm.jdk_ in the path)

… gave it a relevant name (in this case JDK 1.7 - DCE VM), and clicked clicked on Finish:

Next I selected the newly created JDK mapping from the Execution Environment drop-down:

And clicked on Run

The console window gives us a confirmation that we are running from the jdk1.7.0_45_dcevm.jdk path (see first line in screenshot below)

And so do the _ Installation Details_ from the newly started Eclipse instance:

Next is was time to make some live changes, for example a) on a preferences page description (see top editor) or b) adding a new static field (see bottom editor):

And although it didn’t work when I had it running under Run (which was expected), when I restarted eclipse under Debug , it hang as soon as I:

1) executed a script that loaded one of the classes I wanted to changed (i.e the target class was loaded into the JVM)
2) made a change in the host eclipse and saved it (which triggered the compilation of that file and the creation of a new version of the target class)
3) went back to the ‘under debug’ version of eclipse (which by now hanged with a OSX Spinning_pinwheel )

Which was a bummer since I was really looking forward to using the DCE VM technology.

Note that I also tried running the host Eclipse under the DCE VM, which gave me the same result (that said, on the positive side, I had both Eclipses running under the patched JDK which is quite cool)

The solution was to try JRebel which worked (see my next post)

Using JRebel to HotSwap new Static String fields in an Eclipse Plugin (without Eclipse restart)

After Installing, compiling and failing to use DCE VM for Eclipse Plugin development it was time to give JRebel a go (which is a commercial plugin that costs about ~300 USD per year).

TLDR: It worked and I was able to run an Eclipse Plugin, make big changes in a class already loaded (like adding a new field/method), and have access to those changes without needing to restart Eclipse.

Part 1: Installing JRebel

First step was to install JRebel from the Eclipse Marketplace:

… with these features:

… which took a little bit to install since there were a number of large downloads:

After the installation (and Eclipse restart) we get an alert message that looks like this:

Clicking on the Active your license takes us to this screen:

Clicking on the Evaluate takes us to the JRebel website where we can request a license:

… which is sent immediately (thx Zero Turnaround):

To activate it, I copied and paste the license string (without the pre and post comments) into the provided TextBox , and we get a little visual clue (top left icon goes green) that the license is good:

Part 2: Configure JRebel

To add JRebel to the Plugin project, there were two things to do:

1) add the JRebel Nature:

2) enable JRebel in the desired Run Configuration:

Once that was done, I started the eclipse plugin (under Run not Debug)

Note: there was this message which can be ignored (for now) since I’m not going to use an Java Project or server in this test/PoC

Part 3: Using JRebel to add new fields and methods

With JRebel enabled in the spawned Eclipse instance (the one that loads the TeamMentor Plugin from class files and not a jar), I opened the Write TeamMentor Script UI and wrote a simple groovy script that showed the contents of a static String from the tm.utils.Consts_Eclipse class.

In the screenshot below, the top part (with the java code files) belongs to the host eclipse instance, and the bottom part is the TeamMentor Groovy based Script editor running on the spawned Eclipse instance.

The script above showed how we can write a groovy script that gets the a static value from a class, and the script below shows how to get a list of fields from that class (which at the moment is 3)

The first test I want to do (which is the one that doesn’t work with the current JVM HotSwap) is to add a new static field to that Consts_Eclipse class, and have access to it, without needing to restart Eclipse!

And that is exactly what you can see in the screenshot below :)

Note how there is a new static String field on the top editor (called TEST_NEW), which is then listed by the groovy script below:

A quick glance at the Console view, will also show JRebel in action:

We can use the same technique to have access to its value:

Here is what happens if we try to access a field that doesn’t (yet) exist:

And here is what happens when that ‘non existent’ field is added:

Finally I wanted to see if new methods (instance and static) were correctly handled (since this is the use-case that I need from this technology/technique), and it worked like a charm :)

Note how in the example below, two new methods are added to the Consts_Eclipse class, which are then used (without Eclipse restart) by the groovy script running on the spawned Eclipse instance:

This is REALLY powerful, since I can now work on the Eclipse core APIs (consumed by the TeamMentor plug-in) without needing to restart Eclipse.

Adding and using new API methods, that are consumed by an Eclipse Plugin under development (without Eclipse restart)

This is a variation of the example shown in Using JRebel to HotSwap new Static String fields in an Eclipse Plugin (without Eclipse restart) and its such a cool/powerful workflow that it deserves a dedicated blog post.

Part of the Eclipse Plug-in development toolkit I’m working on, are couple APIs that are inspired/based on my previous work at the OWASP O2 Platform’s FluentSharp APIs (available from NuGet).

The core idea of these Fluent APIs is to simplify to the maximum the code required to perform a particular action.

This means that if you were programming an Eclipse UI, and (for example) you wanted to open a view, you shouldn’t need a lot of commands and instructions.

You should just be able to say: eclipseUI.new_View(“{view title}”);

Which is one of the APIs that I’ve added to the eclipseUI.java file (exposed to the Groovy execution environment) and can be used like this:

What you see above is the Groovy environment described on Programming Eclipse in Real-Time (using an ‘Groovy based’ Eclipse Plug-in) executing the eclipseUI.new_View(“This is the title of a new view”); script, which will create a new view (shown in the bottom panel).

My objective is to create an API (which is really a DSL) that is very intuitive and easy to use.

That means that there are cases where it makes sense to have repeated methods. For example I have already found myself trying to use the method eclipseUI.add_View(“{view title}”); instead of the existing eclipseUI.new_View(“{view title}”); (i.e for some reason, there are cases/workflows where I fell calling that method new_View and others add_View).

Before the JRebel HotSwap capabilities, I would had needed to:

1) go to the main Eclipse (the one running in the background and with the Eclipse plugin source code)
2) add/change the new API Method
3) start a new instance of Eclipse
4) see the result
5) make changes/fixes to the code, and (depending on the location of those changes) restart Eclipse

In fact, since I’m trying to do as much TDD as I can, most of the development should be done using Unit Tests (which adds another layer of execution/complexity). And since Eclipse start-ups can take from 10s to 50s, this workflow really sucked (and killed off any development mojo)

But what I really want is to:

1) add new API Methods (or change existing ones)
2) execute them (without needing to restart Eclipse, AND ideally without changing Eclipse instances)

That’s it :)

And that is what I have now :)

Lets see it in action.

Here is an attempt of using the add_View method, which currently doesn’t exist in the eclipseUI class.

Now, what is really cool, is that I’m going to open the actual TeamMentor.Eclipse.PlugIn.Fortify project inside the Eclipse instance current running that Eclipse plugin. Think of this like being inside the Matrix, opening up the code to the Matrix, changing it and executing it :)

Once I have that project openned (note how there are no compilation errors), I can open the tm.eclipse.helpers.eclipseUI.java file (screenshot above) and add the new add_View(String viewId) static method (screenshot below)

And in the time that it took me to save and switch tabs, the new class was compiled and JRebel did the hotswap :)

Which means that I can now use it in my script:

Which was done:

1) without restarting Eclipse
2) without going to the parent Eclipse (running on the background)

Basically, meaning that I now have the speed of compilation+activation that I need (less than 1 sec), so that I can program at speed of type and without losing any mojo (i.e. I’m very productive)

Here is a final example where I use the new add_View method in conjunction with other methods I had added before to:

1) create a new View
2) add a browser to it
3) open the http://news.bbc.co.uk page

I really like the script shown above, because it is easier to read (today and in 6 months time), and it moves all the Eclipse API complexity to behind the scenes.

NOTE: we still have access to all the normal Eclipse API methods and classes from here, it is just that at this stage they are not needed :)

Groovy Script to create a view that shows the images available in the ISharedImages class

Today I needed to add a couple icons to the Eclipse Plugin I’m working on, and after a quick Googling a bit, I found that Eclipse already includes a number of images with its release, namely via its ISharedImages class.

As with the question at Overview of ISharedImages? I wanted to see a full list of images available, and although that answer points to a couple blog posts that have it (see here and here) that didn’t answer all my needs, since (for example) I also wanted to know if the images were available in the Eclipse versions we currently support (Indigo, Juno and Kepler).

Since I’m still tweaking the eclipse API (in real-time) and learning how SWT works, this was a good opportunity to do the same thing using a Groovy script.

After a hitting my head against the wall for a bit (trying to control a number of SWT Layouts :) ), I was finally able to create what I was looking for (see code at the end of this post or at this gist).

Here is the view running in Indigo:

Here is the view running in Kepler:

As you can see the images are the same (in quantity and looks). Note that I remove the *_MASK images, since I am not sure where they are supposed to be used (and they didn’t look that good in that view)

Similar to what I did for the .NET version (see Added 215 Tango Library Icons to FluentsSharp.BCL and ‘PoC - View FluentSharp_BCL Embeded Icons.h2’), I also added the feature of showing the currently clicked image id in the Selected Image TextBox (helps when looking for a particular image))

To give an idea of how I developed this script, here is the Eclipse instance that contains both the Groovy Script, the created view and an test_ SWT Designer_ editor (to help me with SWT’s syntax). Note that this is the Eclipse instance that is running in JRebel mode (i.e. I can add new API methods to the Eclipse plugin under test, and consume them immediately)

Here is the groovy code that creates that view, with still with too many SWT plumbing for my taste, and definitely a script that will be dramatically reduced in size once I add the required helper methods to the eclipseUI APIs (like what I did for the code that gets the images from ISharedImages) :

Executing Eclipse Plugin JUnit tests in real-time without needing to restart Eclipse (with no mocking)

One of the key capabilities that I wanted to have after Programming Eclipse in Real-Time (using an ‘Groovy based’ Eclipse Plug-in), was to be able to run JUnit tests (including tests using STWBot) in the live (under debug) Eclipse instance (called _test Eclipse _ below).

This would allow me to code in a very quick/efficient TDD workflow, since I wouldn’t have to wait 15s to 30s to see execution results for new JUnit tests or major/minor changes to existing JUnit tests.

The good news is that by using the GroovyExecution API that I wrote for the TeamMentor Eclipse Plugin, I was able to dynamically load and run the class files of the JUnit tests to execute, which was already a massive milestone, since that gave me 80% of what I needed. But it was only after Adding and using new API methods, that are consumed by an Eclipse Plugin under development (without Eclipse restart) and having JRebel enabled, that I had the full dynamic environment (where changes to the main plugin code and changes to JUnit test code did NOT require an Eclipse restart).

Here is a walkthrough of how it works (still a bit rough around the edges , but already a really powerful workflow).

As an example lets look at the tm.eclipse.helpers.images class that I added yesterday to the Plugin Apis (when adding the Groovy Script to create a view that shows the images available in the ISharedImages class).

The objective of this class it to make it really easy to get one of the images that is provided via the ISharedImages class

And what we want is to write a JUnit test to check that it is working as expected.

So in the TeamMentor.Eclipse.UxTests project, I added a new images_Test class,

With a simple test method (which will trigged a fail exception with the message ‘Not implemented’)

Next, I switched to the _test Eclipse _ (the one opened from the dev Eclipse), and wrote this Groovy script:

…which when executed returns this:

… which is the JUnit execution result of the tm.eclipse.helpers.Images_Test JUnit test class (note how the names JUnit test method failed with the Not Implemented exception)

Since in that script there are already a number of helper methods in action, it might be easier to understand what is going on if I de-factored it to this (code in this gist):

Basically what is happening is that I’m invoking the JUnitCore.runClasses static method from this Groovy execution environment (which is running under the current eclipse).

And since my objective is always to make code/scripting as simple as possible, I added the static method dev_Execute_TM_JUnit to the GroovyExecution API, so that we can execute UxTests JUnit tests like this:

Now that we have the ability to execute JUnit tests in the current Eclipse in real-time (did I mention that I don’t have to restart Eclipse in between executions :) ), its time to write the the _Images_Test _test.

Depending if I’m working with two monitors (or not), I usually open the two main files (in this case Images.java and Images_Test.java in the dev Eclipse, in a dev environment that looks like this:

In the image above:

  • Top left is the Images.java file (which is the one we are writing the JUnit test about)
  • Botom left is the _ Images_Test.java _ (which is the JUnit test file)
  • Right is the Groovy Execution environment with only the return GroovyExecution.dev_Execute_TM_JUnit(“tm.eclipse.helpers.Images_Test”); script (which will execute the Images_Test.java JUnit test in less than 1 sec :)
    • Note how in this execution result window/text, the runCount value is 2 and the the names method fail message is Hello JUnit World (which match the small changes I made to the Images_Test.java file before I took that screenshot)

The next step is to actually write the Images_Test.java JUnit test …

… which after a number of executions (all done without restarting Eclipse)

… looked like this:

… with the execution result looking like this:

That JUnit test is a good example of one of the ways I like to do TDD, since I’m also using those tests to check my expectation and understanding of a particular Eclipse API.

XStream “Remote Code Execution” exploit on code from “Standard way to serialize and deserialize Objects with XStream” article

At the DefCon 2013 I co-presented (with Abraham and Alvaro) the “RESTing On Your Laurels will Get YOu Pwned”, which showed a number of PoCs on how REST interfaces and APIs can create a number a security vulnerabilities:

Since that time, I have blogged about a couple of the demos created:

We also showed a PoC using the XStream API (which had been reported to the XStream developers) which so far has not made it into a blog post (the PoCs presented at DecCon are here and here).

Since a quick search for ‘XStream Vulnerabilities’ only shows a couple examples (Spring Source OXM Remote OS Command Injection when XStream and IBM JRE are used, JAVA RESTful Services | Fuzzing Down the Rabbit Hole: Part One and this git commit), I think it is fair to say that this is issue is still quite unknown.

A good example of how the dangers of XStream are not fully understood is the Standard way to serialize and deserialize Objects with XStream:

This blog post shows a ”…standard way of using XStream in profeessional projects to generate XML or JSON or Objects…“ which unfortunately will make any application that uses that API vulnerable to (amongst other things) remote code execution.

As soon as I saw that article, I thought “humm… this looks vulnerable to the XStream code execution vuln we showed at DefCon” and since it was a slow Saturday here in London, I had a bit of time to create a PoC to confirm my assumption :)

After replicating the XMLGenerator API proposed on the Standard way to serialize and deserialize Objects with XStream article (see full workflow I took below), I was able to pop a Calculator on my OSx test box using this script (gist here):

… which when executed, first opened the /Application/Calculator.app and then failed (the XMLGeneration/Stream step) with this cast exception:

Note: we can also use this OSx open command to:

… open the current folder (with an argument of ”.”)

… open a particular webpage (with an argument of “https://www.owasp.org”):

Bottom Line: Be very careful when using XStream

In addition to this remote command execution PoC, XStream allows the creation of server side objects based on reflection (which means that you could have all sorts of business-logic sensitive objects being created).

Note: As the XStreamMarshaller quote shown at the end of this post shows, It looks like there is an official way to limit which objects XStream will create, but I’m not sure on the best practices (please comment below if you know more about how to ‘securely use XStream’)

So how is this possible?

Basically (the way I see it), XStream is an ‘reflection-based XML-to-Object conversion’.

Where XStream takes the XML provided and tries to create Java objects based on it.

Here is an example of the XStream Serializing and Deserializing capabilities in action:

Basically XStream is able to take an XML that represents and object and make it into an nice POJO (which is a great feature and I can see why developers really like it).

The objective of the article in question is to create an API that makes this even simpler:

… which can then be used like this:

To see this in action let’s fire up an new Eclipse project and follow these 23 steps:

1) create a new Java Project

2) call it (for example) XStreamPoC

3) Add a folder called lib

4) Copy to that folder the xstream-1.4.6.jar file that can be downloaded from here:

5) Add the xstream-1.4.6.jar jar to the Build Path of the current project

6) In your browser, open the Standard way to serialize and deserialize Objects with XStream page, copy the contents of the XMLGenerator.java _** file (in the middle of the page), (back in Eclipse) select the **_src folder and select (or type) Paste

7) Note how that Paste created a new Java file with the contents of the clipboard (which is a pretty cool Eclipse feature :) )

8) Go back to the Standard way to serialize and deserialize Objects with XStream page, and do the same thing for the Square.java and Rectangle.java files

Note: at this stage there should be no compilation errors in the current Eclipse project

9) Next add a new class

10) … called XStreamPoC (note tick the public static void main(String[] args) checkbox before clicking on Finish)

11) on the Main method add a simple test System.out.Println command and run the project as a Java Application

12) Which should look like this:

13) Now it is time to use the XmlGenerator usage samples from the Standard way to serialize and deserialize Objects with XStream page:

14) Which when executed should look like this

Note: in the image above we can see the type of ‘clean’ XML that XStream expects to consume.

15) Next lets remove the serialisation part and just look at the process of converting XML strings into Objects.

In the image below you can see both cases (using the XmlGenerator.generatorToFromXML and the respective XStream code)

16) What is interesting/dangerous about the XStream API, is that it will create the object as defined in the XML file. Note how in the example below, the Java string is created first, and then attempted to be casted into the Square class

17) we can confirm that the Java string is indeed being created ok, if we remove the case to Square and treat the sq1 variable as a Object

18) Here we create a Java string based on its full signature:

19) Which means that we can create any object that is currently loaded in the class path (and we can create the required objects to invoke its constructor).

The next example shows how to create an instance of the InitializationException class:

20) And this one how to create a _ java.lang.ProcessBuilder_ object

21) Note that the cast error (using the original code) will occur after the ProcessBuilder object is created

22) At the moment we still have a problem that we are only creating objects, not invoking them. That is where the dynamic-proxy + EventHandle technique comes into play.

First lets see how to invoke a method (in this case the start from the ProcessBuilder object) using a variation of a code sample from Alvaro’s thread with the XStream developers:

Note: The cast exception happens when the TreeSet Comparable invokes the EventHandler (which returns the execution result of the start method)

23) the final step is to convert the TreeSort code shown above into XML seen below (I used the XMLGenerator.generateXML to help in the creation of the final payload (which is a variation of the payload we showed at DefCon)):

Note: here are XML examples of the inputs supported by the multiple XStream converters

Conclusion: Be very careful when using XStream and don’t feed it XML retrieved from untrusted sources

Hopefully this post shows how dangerous it is to create APIs like the XMLGenerator one.

What Srinivas Dasari article also shows, is that unless these type of dangers are clearly mapped, identified exposed and visualised, it is just about impossible for developers (like Srinivas) to understand the dangers of the APIs they are are consuming.

Appendix A) Source code

All code samples shown in this post are on this gist

Appendix B) XStream in the Spring Framwork

The original PoC Alvaro created for XStream used the Spring Framework XStreamMarshaller which provides this guidance at the end of this doc:

How to create (using Eclipse) JavaDocs that looks good? (My current approach is not working)

I want to create nice JavaDocs for the API I’m developing for TeamMentor’s Eclipse Plugin Builder Kit (see here , here and here) , but at the moment I’m not having the results I want (see at the end of this post screenshots of the type of JavaDoc I want to create).

Here is the workflow I’m using to create the JavaDocs in Eclipse (Kepler):

1) Select the menu item Project + Generate Javadoc…

2) In the Generate JavaDoc wizard that pops up, chose the project to create the JavaDoc and click Next

3) In the next screen, enter a Document Title , don’t chose a Style Sheet (we will try that later) and click Next

4) In the final step of the Wizard, click on Finish (note that the option to save it as a Ant Script is really cool, since that way we can automate this process using Ant)

5) This is what the created Java doc looks like (which is now what I wanted):

6) Next, I tried using a css (which I got from here) that I saved on a project’s folder and mapped it on this Generate JavaDoc wizard page:

7) And although it looked better:

8) It is still not what I wanted:

9) Here is an example of the JavaDoc style that I would like to create

10) Which looks much better:

So my question is: How do I create JavaDoc that look like the screenshot above?

One thing that might be affecting the current result, is that I’m compiling the Eclipse Plugin using Java 6 (to make it compatible with it), any maybe the desired JavaDoc style is part of the java 7 and I need to use the JavaDoc version that comes with JDK 7 (note that the stylesheet.css used was from JDK 7)

5. January 2014

  • Updating the GitHub repos for the 1.6.0 release of the Eclipse Fortify Plugin
  • Saga to sign an eclipse plugin with a code cert
  • Fixing Coding Signing issue where Eclipse Plugin didn’t install in Indigo
  • Eclipse Groovy script to remove the ‘busy’ image from the WebBrowser Editor
  • Viewing Eclipse and SWT objects (Workbench, Display and Shell) using Groovy’s ObjectBrowser and using TeamMentor’s Plugin ObjectBrowser

Updating the GitHub repos for the 1.6.0 release of the Eclipse Fortify Plugin

As you can see by the recent eclipse related posts, I have been working on a Plugin for Eclipse that shows TeamMentor guidance to users that have access to the Fortify Eclipse plugin (and *.fpr files). We are now in the final stages of releasing the first public version (1.6.0) which is actually made of two parts: An Eclipse Plugin builder (which is Open Source) and a small ‘Fortify Specific’ code-mapping script. Very soon these will be in separate projects, but for now they are all hosted at the TeamMentor/TeamMentor_Eclipse_Plugin.

This post is just to document the current GitHub development model and where to find the main parts of this release.

As mentioned above, the master version of the code is at TeamMentor/TeamMentor_Eclipse_Plugin which currently looks like this:

One interesting point here is that for this release I did not use my main GitHub DinisCruz account, but used instead a much less powerful GitHub DinisCruz-Dev account.

To see this in action, note how the Pull Request commits (into the master and develop branch) are made using the DinisCruz account:

… and the development commits are made using the DinisCruz-Dev account:

What I did was to fork into the DinisCruz-Dev account, the TeamMentor/TeamMentor_Eclipse_Plugin repo:

… which was then used during development (which in practice means that the DinisCruz-Dev account does NOT have commit privileges to the release version of the code base)

In terms of the 1.6.0 release, I also added a Git Tag to it (now possible to do via the GitHub web UI), so that this version can be easily accessed and downloaded from the repo’s Releases page:

In order to help installation and deployment of this plugin in Eclipse, there is also this Eclipse Update site repo TeamMentor/TeamMentor_Eclipse_Plugin_Deploy

… which also contains the v.1.6.0 release tag:

… and can be used inside eclipse using a local clone of this repo, or via this temp update site

https://eclipse-plugin-builder.scm.azurewebsites.net (see more detailed installation instructions at: TeamMentor Plugin and Builder v1.5.6 (Source Code and Eclipse Update site) ).

Now that this release is out of the way, I will try to write a number of blog posts that show how it works and how powerful the Eclipse Plugin Builder is (for example to add support for more tools or easily create eclipse plugins to help developers to write better/securer code)

Saga to sign an eclipse plugin with a code cert

Signing an Eclipse Plugin with a code cert should be simple right?

Well this is probably one of those cases that maybe it is obvious for others with more knowledge on how java code signing works, but I’ve spend the good part of two days trying to sign an eclipse plugin, and finally I was able to get it to work.

I will start with the solution (as executed in OSX), and then talk about the problem:

1) MK (SI’s tech guru), created the SecurityInnovationInc.csr and SecurityInnovationInc.key files using

openssl req -new -newkey rsa:2048 -nodes -out SecurityInnovationInc.csr -keyout SecurityInnovationInc.key -subj “/C=US/ST=Massachusetts/L=/O=Security Innovation Inc./CN=SecurityInnovationInc.”

2) MK then sent the SecurityInnovationInc.csr to Global Sign (as part of their Code-Signing cert service)

3) After a bit (I think about a day or so) MK received from Global Sign two files: intermediate.cer.txt and OS201311137236.cer.txt

4) MK then send me (via a protected channel) a zip with the following files

5) After:
a) renaming the intermediate.cer.txt into intermediate.cer.txt b) renaming OS201311137236.cer.txt into OS201311137236.cer and
c) downloading the GlobalSign Root CA cert from here into GSRoot.cer

I used the cat command to create the server-cert.txt file:

cat OS201311137236.cer intermediate1.cer GSRoot.cer > server-cert.txt

6) With the server-cert.txt I used openssl to create a PKCS12 keystore (server-cert.pkcs12 ) using:

openssl pkcs12 -export -inkey SecurityInnovationInc.key -in server-cert.txt -out server-cert.pkcs12

7) At this stage I was able to verify the PKCS12 keystore (server-cert.pkcs12) using:

keytool -v -list -keystore server-cert.pkcs12 -storetype pkcs12

8) Next with the PKCS12 keystore (server-cert.pkcs12), I was able to create the Java keystore (server-cert.jks), using:

keytool -importkeystore -srckeystore server-cert.pkcs12 -destkeystore server-cert.jks -srcstoretype pkcs12 -deststoretype JKS

9) And finally sign the designer jars using:

jarsigner -keystore server-cert.jks artifacts.jar “1”

10) UPDATE: After I did this, the installation happened as expected on Kepler, but failed on Indigo, The reason is because Indigo doesn’t support SHA256 which is what is used by default by Java 7 (v1.7.0_45-b18) version of JarSigner tool. The solution is to use use the -sigalg and -digestalg options to explicitly use SHA1 (the command bellow also uses the timestamp.dll as TSA (Time Stamping Authority))

jarsigner -keystore server-cert.jks -tsa http://timestamp.globalsign.com/scripts/timestamp.dll -digestalg SHA1 -sigalg SHA1withRSA content.jar “1”

I hope this helps other who are faced with the same challenge.

So what was the problem?

First there is massive soup of keystores, Cert types and other Cert related ‘things’ in play here, with lots of names for the same thing (See the SSL Converter article for a nice list of ‘possible conversions’).

After much reading and mucking about, I think the root cause was the fact that MK didn’t use the java’s keytool to generate the Java keystore as described in Java CodeSigning JKS Method - Certificate Generation and Installation (he used OpenSSL).

This means that I when I tried to create the Java keystore as described in Java CodeSigning JKS Method - Certificate Generation and Installation , I didn’t work because I wasn’t able to import the private cert for SecurityInnovation_.crt.

Another problem was that I didn’t have the GlobalSign root CA, which is needed to so that the verification chain works ok.

The solution (as described above) was to:

  • create a flat file with the 3 certs (OS201311137236.cer , intermediate1.cer and GSRoot.cer)
  • use the flat file to create a PKCS12 keystore (server-cert.pkcs12)
  • use the PKCS12 keystore to create a Java keystore (server-cert.jks)
  • use the Java keystore to sign the Eclipse plugin Jars

Simple once we know how to :)

I went through a ton of different errors, and for reference here are the tabs I had opened when I finally was able to figure out the solution:

Fixing Coding Signing issue where Eclipse Plugin didn’t install in Indigo

As mentioned in the Saga to sign an eclipse plugin with a code cert the problems didn’t finish after the plugin was signed OK.

During the final QA stage Roman reported that he was Unable to install plugin on Indigo.

I was able to replicate that issue on a clean install of Indigo, where I got the following error when trying to install the TeamMentor Plugin:

… and

A bit of research took me to the Install of plugin fails when signed by Java 1.7 jarsigner page, which provided the following explanation:

A plugin that is signed with the Java 1.7 jarsigner tool cannot be installed into Eclipse. In 1.7, the jarsigner tool uses the SHA256 algorithm, which doesn’t appear to be supported by Eclipse.

The solution was found at Signing an Eclipse Plugin with Java 7 and described in step 10 of Saga to sign an eclipse plugin with a code cert:

Use the jarsigner’s -sigalg and -digestalg options to explicitly sign using SHA1:

jarsigner -keystore server-cert.jks -tsa http://timestamp.globalsign.com/scripts/timestamp.dll -digestalg SHA1 -sigalg SHA1withRSA content.jar “1”

After that was done (and all 4 jars where signed (the content, artifacts, plugin and feature)), I was able to install the extension ok in Indigo.

Here is the Plugin shown in Eclipse’s Installed Software view

And here are the signature cert details of the plugin installed:

Eclipse Groovy script to remove the ‘busy’ image from the WebBrowser Editor

Now that I’m doing AngularJS and Firebase development inside Eclipse, there was a little ‘thing’ that was starting to drive me crazy: The animation icon on the top right of the Eclipse WebBrowser!

Apart from the mosaic 2000s look (which is kinda ok), there is a big problem with pages that keep running for a while: the animation doesn’t stop!

This means that if you are developing inside Eclipse, there is this ‘thing’ (i.e. the top right icon) that keeps moving and demand my brain’s attention:

The icons keep animating like this:

Since there didn’t seem to be an preference or option to disable this behavior, it was time to open up the Eclipse Grovy REPL Scripting Environment and fix it with a script :)

The solution

After a quick prototyping, I come up with this script to remove all icons from all opened WebBrowser editors (gist here):

After execution the icon is not there anymore :)

How I found the solution

Here are the steps I took to find the _busy _object to set the visible value to false

1) in the Grovy REPL I started by getting a list the ids of all current opened Eclipse views, but there didn’t seem to be any web browser in there:

2) then I looked at the list the ids of all current opened editors, and found one that sounded promising: org.eclipse.ui.browser.editor

3) to confirm that that was the one I wanted, I looked at the titles of the current editors, and confirmed that the browser window I want to capture was there (the title was “Angular with Firebase Lite”);

4) now that I knew the title, it was easy to get an EditorReference to it:

5) everytime I have an object reference that I want to take a look, I call the show({object}) viewer, since that will give me a nice TreeViewer of all methods, fields and properties ( see Viewing Eclipse and SWT objects (Workbench, Display and Shell) using Groovy’s ObjectBrowser and using TeamMentor’s Plugin ObjectBrowser for more details how this works)

6) in this case we don’t want the EditorReference object. What we really want is the actually editor, which can be retrieved by invoking the getEditor(true) method (note how the object we are currently seeing in the Object Browser is the org.eclipse.ui.internal.WebBrowserEditor)

Here is a better view of this object:

7) looking at the org.eclipse.ui.internal.WebBrowserEditor object, the one that called my attention was the webBrowser field (which is an org.eclipse.ui.internal.browser.BrowserViewer object)

8) Inside the webBrowser object I found the busy field (which is an org.eclipse.ui.internal.browser.BusyIndicator object)

9) and finally inside the busy object I found the visible property (ie the getVisible and setVisible methods)

10) back in the REPL, it was time to do the same thing programmatically.

First I got a reference to the webBrowser field:

… and then the busy field:

11) Once I had the reference to the busy field, it was easy to make it invisible (by just setting the visible property to false)

12) final step was to write a generic script that would work on all opened browser editor windows (a robust script would use the same trick I used in the integration with the Fortify plugin, where a callback is received on every new view opened (i.e. we could wait for new instances of the org.eclipse.ui.browser.editor to be opened, and apply the fix then))

To demonstrate the script in action, here it is the browser before:

… and here it is after:

Note: another way to to stop the constant animation was to just set the stop value to false, but this would only work for the current opened page (i.e. the animation would be back on page reload)

Viewing Eclipse and SWT objects (Workbench, Display and Shell) using Groovy’s ObjectBrowser and using TeamMentor’s Plugin ObjectBrowser

Using the Groovy REPL included in TeamMentor’s Eclipse Plugin (see update site and more info here, here, and here) it is possible to view in real time a number of Eclipse/SWT objects (for example the Workbench, Display or Shell)

Using Groovy’s ObjectBrowser:

Let’s start with Groovy’s ObjectBrowser which I used to use just about every day, since it gave me access to a live view of an particular Object’s Fields, Properties (from getters) and Methods.

To see it in action, open the Write TeamMentor Script view (if don’t have access to it , see install instructions here) which is basically a Groovy REPL (Read Eval Print Loop):

In this Groovy REPL environment, you can write Groovy code that accesses the actual Eclipse objects from the running Eclipse instance:

In the script above we feed the workbench variable to Groovy’s ObjectBrowser, which when executed will look like this:

One of the problems with the Groovy’s ObjectBrowser (an Swing UI shell), is that it doesn’t allow you to zoom-in into inner/child objects.

So for example if you wanted to see the details of the Display object, which is exposed by the Workbench object, you would have to do something like this:

TIP: The Groovy REPL is injected with an live instance of the EclipseAPI object which exposes a number of these objects.

For example we could use the ObjectBrowser to see the workbench, display and activeShell objects like this (using the objects exposed by eclipse.workbench, eclipse.display and eclipse.shell):

In fact, the ObjectBrowser.inspect({object}) is also injected as Groovy method, so we can just use inspect({Object}):

Using TeamMentor’s Plugin ObjectBrowser

Like I mentioned above, although I used to use the Groovy Object browser a lot, I didn’t like its limitations, and eventually I was able to use the simpler SWT API (also shared by this plugin) to create a better version.

To see it in action, you can use this script:

…which will show the new version of the ObjectBrowser inside a native Eclipse view:

… that can be moved around inside Eclipse (as any other Eclipse view), or even opened up in a popup Shell:

This version of the ObjectBrowser (as the Groovy one) takes any object as input, and uses refection to show the fields, getters and methods.

On the left-hand side you can see the initial object provided (in this case the live Eclipse workbench object), which is quite a nice, big and juicy object:

One right-hand side we see a table that shows the fields and getters for the currently selected treeview node

In this case (when ObjectBrowser opens for the first time), the target shown will be the Eclipse’s Workbench object:

But instead of having to load the ObjectBrowser again to see the details of an another _Workbench _object (like the Display), we can just select it form the left-hand side treeview, and its contents will be shown on the right-hand side table:

In fact, you can even expand that node, and selecte other nodes to see the values of its fields and getters.

For example there is the Display object (which is exposed by the Workbench object):

For example here is the current activeShell object (also shown in the Groovy ObjectBrowser screenshots):

TIP: As with the Groovy ObjectBrowser inspect({Object}) injected method, there is also a show({Object}) method that will open the TeamMentor’s ObjectBrowser view directly (with no need to add extra java packages imports):

For fun, you can use the ObjectBrowser to see the fields, getters and methods from an ObjectBrowser :)

Also useful is the fact that if a Collection (or Array) is given to ObjectViewer, the left-hand-side treeview will show each Collection item on its root.

For example, here are all the current visible/active Eclipse views in the current workbench (the eclipse.views.list() API call will be explained in another blog post)

Here are all the Eclipse views that are currently registered (and available) on this instance of Eclipse:

And finally here are all the Eclipse Editors that are currently registed (note that the instance of Eclipse I used to take these screenshots didn’t have the Groovy plugin installed, which is why the Groovy Editor doesn’t show in the list below):

That’s it for this post!

Thanks for reading and I hope you see the value in this ObjectBrowser. I would love to have some feedback, so please take it for a spin, and let me know what what you think of it :)

You can use this update site to install it on Eclipse Indigo, Juno or Kepler (x32 , x64, Java 6 or Java 7)

Alternatively you run it from the source code or install it offline using a clone of the update site files

6. February 2014

  • Creating an Eclipse UI to run AngularJS e2e tests using Karma
  • Using Firebase to sync data with a webpage (via Javascript, REST and Firebase Admin panel)
  • XSS considerations when developing with Firebase
  • Eclipse Groovy REPL script to sync a Browser with file changes (with recursive folder search via Java’s WatchService)
  • Really SIMPLE and clean AngularJS + Firebase example
  • Using AngularJS in Eclipse, Part 1) The Basics

Creating an Eclipse UI to run AngularJS e2e tests using Karma

This post shows how I created a nice set of views in Eclipse to quickly see the execution result of AngularJS e2e (end-to-end) tests, without leaving the Eclipse UI.

The image below shows this UI in action, where:

  • The source code of the test is shown in the Eclipse Java editor
  • Just below is the console out of the Karma runner (which is detecting files changes)
  • On the top-right is the hooked browser (i.e. the one that will run the tests)
  • On the middle-right is the simple AngularJS Hello World page
  • On the bottom-right is the debug view of the hooked browser (which is what you get if you click on the Debug Button included on the top-right page)

Here are the tools and Eclipse Plugins used to create this UI:

Although the AngularJS and NodeJs Eclipse plugins provide nice helpers and views, they didn’t provide (yet) the kind of UI that I was looking for. Namely they didn’t support the use of KarmaJS to run AngularJS tests.

But since I now have the ability to quickly manipulate and create new Eclipse views without restarting Eclipse (using the Groovy REPL script environment ) it was not very hard to create the UI that I wanted (see Eclipse Plugin that allows the execution of REPL Groovy Scripts (in the current Eclipse Instance) and Fluent API for Eclipse+SWT).

Basically the brief was to:

  • Create new (Eclipse) view with a browser showing http://localhost:9879/__karma/ (the KarmaJs browser runner/hook)
  • Create new view with a browser showing http://localhost:9879/index.html (the AngularJS page)
  • Create new view with a browser showing http://localhost:9879/__karma/debug.html (debug view of Karma runner), with an toolbar button to refresh it.

Here is the Groovy code* with the code that creates this 3 Eclipse views:

 1 eclipse.views.create("Karma Runner")
 2          .clear()
 3          .add.browser()
 4          .open("http://localhost:9879/__karma/")
 5 
 6 eclipse.views.create("Website")
 7          .clear()
 8          .add.browser()
 9          .open("http://localhost:9879/index.html")
10 
11 def view      = eclipse.views.create("Karma Runner - debug ").clear()
12                                                                                                 .set.layout.gr\
13 id();
14 def runButton = view.add.toolBar()
15                 .add_Button("run", images.get("IMG_TOOL_REDO_HOVER"));
16 
17 def browser   = view.add.panel()
18              .set.layout.grid_Grab().add.browser();
19 
20 def openKarmaDebug = new Runnable() { public void run()
21     {
22         Thread.start {
23                 browser.open("http://localhost:9879/__karma/debug.html");
24                 view.refresh();
25                  };
26     }};
27 
28 runButton.onClick(openKarmaDebug);
29 
30 view.refresh();
31 
32 openKarmaDebug.run();
33 
34 
35 //Config:UIThread_False

Hopefully this script is easier to read (the idea of the Fluent API that I added to the Groovy REPL was allow the easy reading and understanding of scripts like this).

1) Setting up the environment

Now lets look at how this environment was setup:

We start with a simple AngularJS project test page that will just show the model-binding capabilities of AngularJS (yes I know that all those JS files should be in separate folders :) )

Then I opened up Groovy REPL script environment and wrote the Groovy script shown above:

Clicking on _Execute _will create 3 views:

a) the Karma Runner view:

b) the Website view:

c) the Karma Runner - debug view:

… which (as seen in the first screenshot of this post) looks like this:

Part of this UI (but not created using the Groovy script) is an Eclipse Console with the ‘Karma Runner process’ console out

The AngularJS tests were executed when the Karma Runner view was opened, because the Karma process (configured via Karma.config.js) is set to wait for new browser’s hooks/runners and (on connection or code changes) execute the configured tests.

2) Making changes to existing tests

To see Karma in action, let’s make a test fail :)

The current AngularJS page is basically just echoing/binding the contents of the Name TextBox into the H1 tag:

Here is the test that is currently being executed, which is an e2e test that runs on the browser (just like Selenium or Watin).

Hopefully this type of Fluent API is easy to read:

  • browser navigates to /index.html
  • value is inserted into the yourName input field (the TextBox)
  • the value of the binded element (.ng-binding) is checked to see if it matches

To make this test fail, let’s change just the yourName value:

Immediately after saving the test with the changes shown above, Karma refreshes the hooked browsers in order to trigger the execution of the tests.

And as the image below will show, there is now one failed test:

In cases like this, the Karma Runner - debug is very useful since it will show more details on what happened, and where the test failed:

Just to confirm that the page is actually being loaded and the tests are happening in a real browser instance, if we add an Javascript alert to the current test:

… we will get an alert box in the Karma Runner - debug (note that on the screenshot below we are seeing the image of the final state of execution of the previous test (in this case the ‘A small Angular Test’)

3) Hooking multiple browsers and only failing on Firefox

In order to run the tests in multiple browsers all we need to do is to open the http://localhost:9879/__karma/ page (in the target browser), and a test execution will be triggered.

Note how on the image below:

  • Eclipse is in the background (containing the views previously created and showing the console out of the Karma test runner process)
  • There are 3 stand lone browser windows (Chrome, Safari and Firefox)
  • Firefox (top most window) shows the tests being executed (in green the test executed, in yellow the test being executed)

After execution, a quick look at the Karma runner shows that the modified test failed (as expected) on all browsers:

Just to make sure all is working as expected, let’s create a test that will fail only in one browser.

For example Firefox is the only one that has defined the navigator.userAgent.contains Javascript function (so we can use this to detect Firefox, and create a test that will only fail if executed inside it):

After saving the changes, the tests will be executed on all 4 browsers, with the one test that failed being the one executed in Firefox:

Refreshing the Firefox debug runner, shows the failed test and assert:

4) Setup

In addition to creating the views programmatically, I also setup an Eclipse Run configurations for NodeJS and an External Tools Configuration for KarmaJS.

The NodeJS configuration was done here:

… where I created a Node Application runner that was pointed to server.js

… which contains a simple NodeJS web server (we could also had used NodeJS Express, but that would had added a lot of other ‘stuff’ to this project)

The KarmaJS config was done as an External Tools Configuration

… where I simply run the start.sh bash file

… which starts KarmaJS:

… using this simple _karma.conf.js configuration

]

Note: I started the Karma process like this because there was an issue with KarmaJS finding the NodeJS executable from Eclipse (and at the time I didn’t had time to debug why that was happening)
External References:

Using Firebase to sync data with a webpage (via Javascript, REST and Firebase Admin panel)

If you haven’t seen the Anant Narayanan presentation on AngularJS conference called Building realtime apps with Firebase and AngularJS you are missing something good.

Firebase really seems to fix one of the pain points that I currently have in client-server development, which is how to send/synchronise data across multiple clients (including the server).

I first heard about Firebase from the Wire up a Backend example that can be found at http://angularjs.org, and today I was able to give it a test drive (since I want to use it on the AngularJS front-ends that I’m currently developing for TeamMentor)

1) Creating an Firebase account

Lets start with creating an account and following the Firebase 5 minute tutorial.

The process of creating an account is just a case of going to https://firebase.com

… choosing a username and password (there is also the option to create an account based on an GitHub account)

… and that’s it:

Firebase by default creates a test app, which can be immediately accessed by clicking on the blue View Firebase button:

2) Firebase tour

On first load of the Firebase control panel, we are presented with the offer to take a tour, which is a great way to understand the basics of how it works.

The first step of the tour is to add some data:

… directly on the current’s App data viewer:

After we click on the Add button, we will see that our data is now part of this Firebase App data stream:

Next (after clicking on the See it in action link), we get this mini chat application with 3 messages:

If we add a new message:

… and look back to the Firebase admin panel, we will see the 4 messages (3 added by the Sample Chat Application and the one I added manually)

The final step of the tour is to make a change directly on the Firebase admin panel:

… and confirm that the value was automagically changed in the Sample Chat Application (in real-time with no user interaction)

3) Creating a simple Html/Javascript page to test it out

Note: The next set of example will use code snippets provided by the Firebase Web Quickstart Guide

Since I’m going to use Eclipse (Kepler), the first step is to create a new Static Web Project

… with a simple HTML inside:

… containing the just the firebase.js script import and a simple data setter:

To see this in action inside Eclipse, I opened up the admin Url in a Browser window (I wonder how long until an Eclipse Firebase plugin is created), and I logged in:

4) Setting and Pushing data

At this stage I had the Html at the top and the Firebase admin panel at the bottom (note the required full url in the var myRootRefnew Firebase(…) Javascript code):

Next step was to open a Web Browser with the test page:

… which set the Firebase server side value to “Hello World!” (I have to say it made me a bit nervous to see how easy it was to completely remove an entire Firebase dataset (I wonder if there are backup or transaction logs for Firebase data))

Next step was to try setting some name-value pairs (i.e. a typical JSON string):

… which looked like this after execution (note that I didn’t refresh the Firebase admin panel (it also uses the WebSocket technology to keep itself up-to-date))

Next I tried the push method (which behaves like an array and was the technique used in the chat example):

Here is the execution result (note how there is now an extra TreeNode with the data provided)

5) receiving events

So far we have been setting/pushing data into Firebase, but what is also really powerful, is that we can subscribe to server-side events, and update the browser/ui when content changes.

The example below shows how to get a callback every-time a new item is added:

Now on refresh (screenshot below), the new children will be shown on the page:

One observation, when we subscribe to the child_added event, any changes made directly in Firebase’s admin panel:

… will only be seen when we refresh the page (where all items are viewed as new children)

To see the changes in real-time, we need to change the event to child_changed:

Now (on refresh) we get an empty list:

… but if the content is changed on the Firebase admin panel:

… the child_changed event is triggered, and we will the new content changes on the browser (without page reload)

5) Consuming and Sending events using REST API

Now that we can create and consume Firebase events using Javascript, it is time to try their REST API.

For that, I’m going to use the Eclipse Grovy REPL Scripting Environment 1.6.0 so that I can do it directly from Eclipse

Note: most scripts shown below are on this gist

The first test was to get the current data set, which is easily retrieved via a simple GET request to the Firebase url for the current application (with a .json appended to in the end of the admin url):

Since we are in eclipse, here is the code to open the JavaScript Editor programatically with the json data received:

By default the data received from the server has no formatting:

But since we are inside the Eclipse JavaScript Editor if we assign it to a variable, we can easily format it:

After doing this, I discovered that if we pass a ?print=pretty to the Firebase url:

… the received json data will already be nicely formatted:

In the example below I used the Groovy REPL Execution result window to see the formatted json data:

Next thing I wanted to try was to see how a REST change would be shown in real time in the browser.

Because my next REST request will use the HTTP PUT command (which is equivalent to the Firebase set Javascript function), I changed the Html page to display and listen for Firebase values (vs arrays with name-value pairs)

Note the snapshot.valueOf().val() command below:

After browser refresh, this is what the test page looked like (with the current message value being set by Javascript on page load):

Next I used the Groovy script below to send a PUT command (I could also had used the Groovy HttpBuilder or the Java Firebase libraries):

When executed, this script will change the value of the current Firebase app to “Data from Groovy!!!!”, which will be shown in real-time (i.e. no browser reload) in the opened test page:

We can also submit (i.e. PUT) name-value pairs:

… which will look like this on the Firebase admin panel:

Next test was to see how to use POST (instead of PUT) on the REST API (in order to replicated the Firebase push command).

To see the result, I changed back the html page to handle items (vs ‘a value’), and changed the on event hook to be child_added:

On refresh, this is what the test page looks like:

… and if we send data using POST on the REST call:

… we will get a callback in real-time (again with no browser refresh):

A real cool feature of Firebase is how easy it is to create new namespaces (or areas/objects) for specific types of data.

For example, if I add Area51 to the firebase url (see the highlighted text below)

… the data will now be stored inside an Area51 object/area/namespace on the current Firebase app:

6) Programatically add new items to the Chat window

Finally coming back to the chat window (see below), when I saw that example, one of my first questions was “How to programmatically submit data to it?

Hopefully by now you should have a clear picture of how to do it, but just in case, here is how I did it :)

For reference, here is what the data looks like:

Here is the script that submits the POST data to this chat (the key is in the chat.json part of the URL)

And now, after executing the above script, the chat window will contain our new message:

XSS considerations when developing with Firebase

Following my previous post on Using Firebase to sync data with a webpage (via Javascript, REST and Firebase Admin panel), here are a couple security notes and ‘areas of concern’, that should be taken into account when developing real-time apps with Firebase:

  • Firebase will reflect any payloads sent to it
  • We are talking about DOM based XSS
  • The current browsers XSS protection does not protect against DOM based XSS
  • It is very easy to create a vulnerability (as you will see below, all it takes is a simple change from .text() _to _.html())
    • If powerful DOM based API-manipulation frameworks are used (like jQuery), there are many more injection points (sinks)
  • By nature of Firebase applications, the XSS exploit will have wormable capabilities (i.e. it will be able to distribute and self-propagate itself VERY quickly)
  • Current static-analysis tools will struggle to pick up this type of vulns

Note: I think (and I will want to double check this) that if is safe (i.e OK) to put received Firebase data/payloads, on an AngularJS auto-binded location/variable (for example {{name}} : {{message}})

Let’s use the chat application provided by Firebase to see this in action (note that as you will see below, the chat application as provided by Firebase, is secure and not exploitable)

1) Example of safe code

If we send an simple HTML payload (like the one shown below) to Firebase:

… by default, the output will be correct encoded, and the HTML will not be rendered (see below):

The reason this happened (the encoding) is because the jQuery.text(…) function was used (see below) when creating the HTML Element to add to the page:

2) Example of unsafe code

But if we change jQuery.text(…) to jQuery.html(…):

… and a more interesting payload is injected (in the case below $(‘div’).html(‘xss’) which will change the html content of all divs to ‘xss’)

… we will see that the payload was triggered on our local test page:

A quick look at Firebase’s data feed, will confirm that the payload is currently stored (and ready to be deployed/pushed to any vulnerable clients).

Not really a Firebase problem

It is important to note that this is not really a problem with firebase, since they are just storing data.

That said, due to the dangerous outcomes of such exploits, I would be interesting if some ‘defense in depth’ capabilities (and validation) could be added to the data stored (I wonder if there is any filtering or sanitization capabilities in Firebase?)

Eclipse Groovy REPL script to sync a Browser with file changes (with recursive folder search via Java’s WatchService)

Since I am using Eclipse to develop using AngularJS (see Creating an Eclipse UI to run AngularJS e2e tests using Karma), I needed a way to refresh the browser window every-time I made changes to any AngularJS related file (note that due to the nature of the AngularJS projects, I need the change to trigger on any change made inside the root folder and all its subfolders).

Since there didn’t seem to be an easy way to do this (‘auto browser refresh on file changes’) in Eclipse, I used the Eclipse Grovy REPL Scripting Environment to develop a script/macro that:

  • Based on a title of an opened eclipse editor file:
  • … find the full path of that file, and:
  • … create a Java WatchService that monitors the file’s folder and subfolders, and:
  • … when a StandardWatchEventKinds.ENTRY_MODIFY is received :
    • Create/Open a new Eclipse view with a browser (called Synced Browser), and:
    • …refresh the index page

For reference here is the groovy code for this script (gist here):

Originally I had tried to use Eclipse file change events (like on this SO thread), but that didn’t work as well as the WatchService.

A next step is to create a mini UI to allow the configuration of the target files (maybe as a view added to the next version of the Groovy REPL Eclipse plugin)

Seeing it in action

Here is how to test this script:

1) create a Web project with an Html file on it:

2) run the Groovy code in the REPL window (note that the image below is using a different root file and the version of script is an older one (which didn’t contain the recursive folder monitoring)):

… on execution you will see a new view (called Synced WebBrowser) show up in your current Eclipse instance.

3) make some changes on the Html file

4) and note that the Synced WebBrowser view will be refreshed automatically (it takes about 500ms to 1s for the change to be picked up (see this SO answer for why I had to use the SensitivityWatchEventModifier.HIGH setting on the WatchService))

5) if you open the TeamMentor Console, you will also see a number of log messages that help to see what is going on:

6) here is another example where I added a new Bootstrap css div:

7) which was immediately (~500ms) shown on save

8) note that the the log message shows the events being triggered and the resetting of the WatcherService:

Really SIMPLE and clean AngularJS + Firebase example

As seen on the First PoC of sending TeamMentor’s server-side request URLS to Firebase (and seeing it in realtime in an AngularJS page) I created a Simple AngularJS website which I’m very happy with (and I mean Simple with a capital S).

The main reason I really like the solution shown below, is because it represents a number of really nice, clean and Simple solutions for common (complex) problems that exist while developing in Javascript.

The created application is an:

  • AngularJS real-time viewer for HTTP requests,
  • … made to an ASP.NET web application (TeamMentor),
  • … captured by an custom C# HttpHandler filter,
  • … submitted to Firebase using its REST API and
  • … pushed back to the AngularJS app using open HTML 5 WebSockets.

The image below shows what the AngularJS+Firebase application looks like, with the urls shown in the background browser being the ones requested when the TeamMentor website is loaded or navigated (note that the latency between ‘request made’ and ‘request listed’ is really small (about ~ 50 milliseconds)):

What I also like about the AngularJS structure that I ended up with, is that it represents a great way to learn AngularJS’ architecture and capabilities (and yes I know and agree that for bigger AngularJS apps it is better to organize by feature and group the multiple files under a dedicated folder (for example the login controller, service, factory, view and tests should all go under the same logical folder))

This post contains a tour of the multiple files created (gist here) which where developed/refactored while in Eclipse using the Eclipse Groovy REPL script to sync a Browser with file changes (with recursive folder search via Java’s WatchService)

Folder/File Structure:

Inside an Eclipse Web Static project, I created a file structure with:

  • _index.html _as the main AngularJS file (i.e. this is the single-page application file)
  • all javascript files were placed in the _js _folder (with the file names providing a clue on what they are doing/providing)
  • 1 directive created in the directives folder
  • 3 views placed on the views folder

1) Index.html

This is the file loaded directly by the browser, which is made of:

  • External/Framework javascript includes: angular.js, angular-route.js, firebase.js, angularfire.js, bootsrap.min.css
  • AngularJS javascript includes (for the current application): app.js, factories.js, controllers.js, directives.js, routes.js
  • CSS link to bootstrap.min.css
  • Html body (containing the AngularJS _ng-app _ directive) and:
    • div tag with container css class
    • h3 tag with alert-success css class (which creates that nice green top banner)
    • the custom top-menu directive (using attribute instead of element)
    • the AngularJS ng-view directive

Since I’m using the AngularJS Eclipse plugin, hovering the mouse op top of an AngularJS directive provides a nice description of they do.

Here is the ng-app directive

… and here is the ng-view directive:

2) app.js

This is where the project module is created (with two dependencies ngRoute and firebase).

Since I moved the controllers, factories, directives and routes into their own separate js file, there wasn’t much to do here, apart from creating global values for the firebase URL and auth token (which will be dependency injected into the controllers and factories)

3) controllers.js

This file contains 3 controllers: DebugCtrl, MessagesCtrl and RequestsUrlCtrl (each will be used on a specific view)

Note that each controller has services injected into them (the AngularJS $scope and the custom fbDebugMsg, fbRequestUrl, fbaDebugUrl)

The DebugCtrl _is currently just adding the injected _fbDebugMsg and fbRequestUrl services into the $scope so that we can see them in the view (this is a nice trick to get an inside view of AngularJS objects)

The MessagesCtrl is using the Firebase AngularFire API, which is makes it really easy to create the firebase-real-time update view (my only problem with this was that there didn’t seem to be an easy way to re-order the new elements (which in the current AngularFire implementation are added at the end of the provided array)

The RequestsUrlsCtrl uses the default Firebase Javascript API (i.e not the AngularFire one) which gives us more control on how to handle the data received by Firebase. The $scope.urls array is used to store the data received from the Firebase child_added event (one note here to say that the Firebase child_added will also provide the entire data-set on first load, which is okish, but I would prefer that the child_added only fired for new events)

4) directives.js

This is a simple directive used by index.html, that will display a top menu, created by the content of the topMenu.html file (directives are AngularJS way to creating/defining new HTML tags/attributes)

5) factories.js

These factories create the Firebase mappings, namely they define the ‘area’ (or namespace/object) that the data will be read from.

The first two (fbDebugMsg and fbRequestUrl) use the Firebase Javascript API. I needed to do them this way so that I could add the Firebase auth token (that said, I’m sure there is a better way to do this in Angular, since ideally I would have an Angular service that took the two variables that need to be set: the target Firebase area and auth code)

The fbaDebugMsg is just a simple service/factory to return an AngularFire API object based on the (dependency injected) fbDebugMsg service

6) routes.js

The routes configuration is basically defining the 3 available views (each with a different controller mapped to it)

7) requestUrls.html (view)

Since the RequestsUrlsCtrl is responsible for updating the $scope.urls array, all we need to do here is to use Angular’s ng-repeat directive to create a list with all items (the list-unstyled class hides the bullet usually shown in HTML <li> tags).

Note that since the RequestsUrlsCtrl controller is using the Firebase Javascript API child_added event, we will see new entries shown in real time (ie. no browser refresh needed), but any changes made to existing items will not be reflected on the UI (unless the entire page is refreshed and the data is reloaded)

8) messages.html (view)

In this view the $scope.messages (used in the ng-repeat) is populated by the MessagesCtrl controller which is using the AngularFire API. This means that data will be updated in real time (on both add and change events)

… which look like this:

9) debug.html (view)

This view just shows a json representation of the fbDebugMsg and fbRequestUrl

… which looks like this:

10) topMenu.html (directive templateUrl)

Finally this is the html that creates the top menu (this could be improved/refactored by having the url and titles being provided as a ng-model object)

All code:

For reference here is the entire source code (gist here) of the source code files shown above.

Using AngularJS in Eclipse, Part 1) The Basics

This covers the The Basics example from AngularJS’s home page:

I’m doing this on an OSX laptop and the first step was to download and unzip (eclipse-standard-kepler-SR1-macosx-cocoa.tar.gz (32bit version of Eclipse’s Kerpler) into the ~/_Dev/_AngularJS folder.

I fired up eclipse, chose the ~/_Dev/_AngularJS/workspace as the workspace root and installed the Eclipse Grovy REPL Scripting Environment 1.6.0 (update site) and Angular-JS Eclipse Tooling (update site) plugins.

1) Creating an Angular JS Project

After restarting eclipse, I right-clicked on the Project Explorer view and chose the New -> Static Web Project menu item

… set AngularJS_Tests as the project name and clicked Finish

… switched to the Web Perspective

… with the Project Explorer view now looking like this:

With the final setup being the conversion into an AngularJS Project

2) Creating the The_Basics.html file

To create the first test file, I right-clicked on the Web Content folder, and chose the New -> Html File menu option:

… set the file name to The_Basics.html and click on Finish

NOTE: The reason this first file is called The_Basics.html is because I’m going to be using the examples from AngularJS’ home page http://angularjs.org/

Once the The_Basics.html file opens up in eclipse

… I change its contents to the code sample from http://angularjs.org/

Note how the AngularJS Eclipse plugin successfully detects the Angular attributes and showed relevant information about it.

Here is ng-app:

Here is ng-model:

3) Fixing the undefined Attribute name issue

Since I used Eclipse’s Static Web Project, when I saved the The_Basics.html file, the following error occurred (if the Eclipse’s Html validation settings are the default ones):

… which basically means that Eclipse is not recognising the AngularJS Html attributes:

To fix this, I went to the AngularJS_Test project’s Properties, opened the HTML Syntax page (from the Validation section) and set to false the Undefined attribute name **setting (in the **Attributes options , not the Elements one)

With that config change, there are no problems in this page, and hovering on top of one the AngularJS directives will show the correct tooltip:

4) Viewing and previewing the The_Basics.html page

Since at the moment we only have one page, we can view it directly without needing a Web Server.

To do that, I clicked on the html file and chose the Web Browser option from the Open With menu:

This will open the default Eclipse Browser

… with the AngularJS test working as expected (in this case any text typed in the Name TextBox will automatically be shown in the page:

We can also preview some of the changes in real time, by choosing the Web Page Editor:

… which will look like this (note the non-processed HTML at the top and the HTML code at the bottom):

Opening up the Preview tab (from the default Design tab) will allow us to test the page currently being edited (note how Angular JS is working):

This means that (when in the Design tab) we can edit the AngularJS HTML page and see the changes immediately:

NOTE: This version of the Web Page Editor **doesn’t render the CSS while in that **Design mode, which means that if we add bootstrap to this project:

… the CSS will only be visible when in the Preview tab:

4) Creating a Git Repository for the files created

The best way for me to share these files is via a Git Repository, so the final step of this post is to create one on the files we have already created.

Since we are in eclipse I tried to create an Git Repo for the current project:

But the Git Repository wizard:

… didn’t work, because it expects the target folder to not exist:

This was easily solved via the command line (by executing $ git init on the AngularJS_Tests folder)

Now that we have a git repository, I was time to open it:

… using the_ Git Repositories_ view

… where we can use the Add an existing local Git repository link:

… to open the repository just created:

In order to create a git commit, I also opened the Git Staging view:

This is what these two git views look like (note that there are no commits/references and the list of new files in the Unstaged Changes list)

To commit the files drag-n-drop them from the Unstaged Changes to the Staged Changes, and write a commit message:

After clicking the Commit button the Git Repositories view will give a visual representation of the location current HEAD (which is the commit just done)

7. March 2014

  • Programmatically changing an AngularJS scope variable and adding Firebug Lite to an AngularJs app
  • Why doesn’t Eclipse community stand-up more to IntelliJ?

Programmatically changing an AngularJS scope variable and adding Firebug Lite to an AngularJs app

In this post I’m going to show two really nice tricks that help when developing AngularJS applications:

  • adding Firebug Lite to the current browser
  • changing the scope value outside a normal AngularJS controller, service or module

Let’s say that we are inside Eclipse and have this simple AngularJS app (gist here)

… which looks like this when executed:

To add Firebug Lite to this page, all we need to do is to add a script reference to https://getfirebug.com/firebug-lite-debug.js

… and after refresh we will have a nice Firebug Lite console (and other nice goodies) at the bottom of our page :)

Next lets see how to access and change the AngularJS $scope of the ContactController.

The objective is to access programmatically the New Contact value (set below to Hello Firebug :) )

In Firebug Lite, we can access the scope object by executing: var scope = angular.element(document.body).scope()

… and the New Contact **value value using: **scope.newcontact

If we change the New Contact value here (in Firebug Lite) using scope.newcontact = “Hello AngularJS”

… we will notice that the value will not automagically (ala AngularJS way) change in the binded (via ng-model) input field

The reason that didn’t happen is because the change was done outside the AngularJS $digest cycle.

The solution is to call the scope.$apply() function (and the input field will be updated):

Why doesn’t Eclipse community stand-up more to IntelliJ?

When I posted to reddit a link to my recent Eclipse Groovy script to remove the ‘busy’ image from the WebBrowser Editor post, the thread what I hoped would happen would be one around the idea of ‘fixing in real time minor (but-very-annoying) issues that exist in the IDEs that we use everyday’

After all, there are very few IDE environments that allow that kind of real-time programatic access to the current running IDE (which allows the creation of new ‘plugin-like functionality’ without needing to run an ‘IDE dev instance’ on the background).

For reference, the reason why I took the time to develop the Eclispe Grovy REPL Scripting Environment, was because I did the same on this VisualStudio C# REPL extension, and knew how powerful (and useful) it was to have the ability to ‘script the IDE’

Back to the reddit there, in a probably predictable way, the only comment I got on that thread:

.. was to stop using such ‘crappy IDE’:

Unfortunately this is actually a common theme on the Eclipse world, where there is a ‘group think view’ that eclipse sucks, its bloated and not really innovating.

Well, I hope that you can see by the number of blog posts that I’ve written so far (31 at the moment), that I don’t share this view.

And here was my answer

I’m committed to make Eclipse a great IDE, and I hope that my ideas, plugins, contributions and blog posts help Eclipse to become the best IDE out there (at least for Java and Javascript development)

But it is going to be an uphill battle since the mood out there is very anti-eclipse. Here are a couple posts that turn up on google (indexed by date):

In trying to find a balanced view (ie. posts with comments from the people who love Eclipse), I really struggled:

The only positive note that I could find was from Jan 2013 where in the Which IDE do you prefer, Netbeans, Eclipse or IntelliJ? Eclipse had the majority of votes.

I’m sure there is a large number of happy Eclipse users out there (I’m one of them), but as you can see by the links above, there is an ‘internet group-think’ mode at the moment in favour of IntelliJ.

Update: if you want to add your views on this question, but prefer to use reddit, here is the thread about this post