Archive for the ‘Plugins’ Tag

Contributing to JSDT #3 : Build Targets on the bleeding edge

I’ve been documenting how to use JSDT to do some HTML5/CSS/JavaScript development. In order to poke around the JSDT code to understand it better, I spent a bit of time figuring out how to get things checked out, built and running. The instructions on the JSDT site a re a bit sparse, so I thought I would document what I did.

I’m not on the JSDT team, so this may not be exactly how they do it. But it works for me.

Previously

My code no longer compiles!

This morning, I updated all the code I previously checked out.  And now my rhino.ui project has a compilation error in RhinoTabGroup:

After a little investigation, I determined that RhinoTabGroup is using a new 3.7 method in AbstractLaunchConfigurationTab.  It has just been introduced.  I’m building against Eclipse 3.6, so don’t have this method.

So if I want to keep my JSDT source code in sync with the latest, I’ll have to also keep up with any dependencies.

One idea to resolve this would be to download the latest milestone builds and put them in my build target.  However, this change is very recent and is not in a milestone build yet.

Another idea is to check out the latest o.e.debug.ui project and any dependency projects (hopefully not too many).

Check out more projects

To add the eclipse CVS repo, copy this into the CVS Repositories View:

:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse

And check out org.eclipse.debug.ui and org.eclipse.debug.core projects

And the compilation issue is resolved.

Going Forward

Going forward, my build target and workspace projects will change often.  I’ll need to actively modify these to keep things rolling along.  I’ll be doing a combination of:

  1. Including other Eclipse projects in my workspace, on an as-needed basis.  I’ll start getting a good sense of what these projects are as things break.
  2. Change my build target to move up to Milestone builds.

Next: Launching the JSDT Unit Tests

Contributing to JSDT #2: Checking out the Code

I’ve been experimenting with the JSDT to try some HTML5/CSS/JavaScript development.  In order to poke around the JSDT code to understand it better, I spent a bit of time figuring out how to get things checked out, built and running. The instructions on the JSDT site are a bit sparse, so I thought I would document what I did.

I’m not on the JSDT team, so this may not be exactly how they do it. But it works for me.

Previously

Adding the CVS Repositories:

Now we’ll add the 2 CVS repositories required to check out the JSDT code.

  • Switch to CVS Repository perspective.
  • Paste the following lines of text into the CVS Repositories View to add web tools and tools as known repository locations.

:pserver:anonymous@dev.eclipse.org:/cvsroot/webtools

:pserver:anonymous@dev.eclipse.org:/cvsroot/tools


Import the projects using a Project Team Set:

The JSDT project provides a project set file, which can be useful for checking out a set of related projects.  Download this to your file system.

In the Java Perspective, right-click in the Package Explorer and choose Import… – Team Project Set

Select Next, Choose the file you previously downloaded.

You will be prompted to reconcile the repos designated in the Team Project Set file and those in your workspace:

Hit OK.  The projects should be imported into your workspace and built.

Missing Projects:

If your projects don’t all compile, you may be missing a project or two.

Currently, the Project Team Set file is missing the debug.rhino.ui and debug.transport projects.  A bug has been fixed and I’m assuming the new project set file should roll out to the web-site in a few days.

You can check out these projects by browsing the webtools CVS repo from the CVS perspective:

Go to webtools / HEAD / org.eclipse.jsdt / plugins.

Right click on the project you want to check out and select ‘Checkout

Project List

With everything compiling and launching, I have the following projects in my workspace (as of 8/30/2010):

org.eclipse.wst.jsdt.core
org.eclipse.wst.jsdt.core.tests.compiler
org.eclipse.wst.jsdt.core.tests.model
org.eclipse.wst.jsdt.debug.core
org.eclipse.wst.jsdt.debug.core.tests
org.eclipse.wst.jsdt.debug.crossfire
org.eclipse.wst.jsdt.debug.rhino
org.eclipse.wst.jsdt.debug.rhino.debugger
org.eclipse.wst.jsdt.debug.rhino.tests
org.eclipse.wst.jsdt.debug.rhino.ui
org.eclipse.wst.jsdt.debug.transport
org.eclipse.wst.jsdt.debug.ui
org.eclipse.wst.jsdt.doc
org.eclipse.wst.jsdt.feature
org.eclipse.wst.jsdt.manipulation
org.eclipse.wst.jsdt.support.firefox
org.eclipse.wst.jsdt.support.ie
org.eclipse.wst.jsdt.ui
org.eclipse.wst.jsdt.ui.tests
org.eclipse.wst.jsdt.web.core
org.eclipse.wst.jsdt.web.support.jsp
org.eclipse.wst.jsdt.web.ui
org.eclipse.wst.jsdt_sdk.feature
org.eclipse.wst.jsdt_tests.feature
org.mozilla.javascript
releng.jsdt

Notes:

Updated: In the CVS repo some of the projects seem to live in both webtools/HEAD/org.eclipse.jsdt/<project> AND webtools/HEAD/<project>.  From some help on the forum,  I’ve found out these are one and the same.

Next: Build Targets on the Bleeding Edge

Is upgrade to “Eclipse RCP, 2nd Edition” worth it?

Today I received my copy of the Eclipse Rich Client Platform, 2nd (McAffer, Lemieux, Aniszczyk).

If you are interested in RCP development, this is the book to own.

But if you already own the 1st edition, is it worth buying the newer edition?  So you can decide for yourself, here are the major differences:

Software management. This chapter has been re-written to discuss software management using p2, which replaced the Update Manager

Action and Commands.  A chapter has been added to discuss the newer Commands API, as well as their differences with Actions.

Installing and Updating with P2.  More p2 information

PDE build. PDE Build is one of the more error-prone and time consuming aspects of working with Eclipse products.  (It’s also powerful and useful.  This chapter is completely reworked.  Lots of clarification as well as updated information.

Testing. A new chapter on testing an RCP application.  A great addition to the book.

A DataBinding reference chapter has been added.

One other thing I really liked was the new font– much more readable IMO.  I also like the Pointers section at the end of each chapter.  Very nice touches.

Essential Plugin: Platform ‘Core Tools’

I wanted to mention another Essential Eclipse Plug-in: the Eclipse Platform Team’s ‘Core Tools’.  I consider it essential to my work based on its inclusion of a single tool: “Find Unreferenced Members”.

Armed with this tool and some unit tests, you can really clean up some code.

Plug-in developers are the primary audience for ‘Core Tools’.  It contributes tools for validating plug-ins/class loading and Eclipse metadata browsing.  You can find more info on its capabilities here: http://www.eclipse.org/eclipse/platform-core/downloads/tools/readme.html.

The essential tool to any Java developer is “Find Unreferenced Members”.

  • Right click on a project, package, or file.
  • Select “Find Unreferenced Members”.
  • A Search view appears with member candidates for removal.
  • Note the matches are only a good set of candidates.  The tool analyzes the Java code in your workspace to determine unused members.  There may be false candidates.  For example, a no-arg constructor might be unreferenced, but as any plug-in developer knows, it’s required if the class is instantiated via plug-in.

The update site is here: http://www.eclipse.org/eclipse/platform-core/downloads.php#updates.

Update: It’s now here:  http://eclipse.org/eclipse/platform-core/updates.

Tiniest Useful Plug-in: Enable “Save All” Button

I like having the Save-All toolbar button in Eclipse.  I feel lost without it.  I almost never hit Save and Ctrl-Shift-S just doesn’t work for me.

Awhile ago I wrote this little plug-in that does only one thing: adds the Save-All button.  Seems like others might want to use it too.  The plugin can be found here: http://sites.google.com/site/kellicker/home/plugins.

Essential Eclipse Plugins: Grep Console

This week I’ve been debugging a rather hairy problem, and one of the few tools at my disposal was to add debug logging to the code.

That’s where Grep Console–a tiny but mighty Eclipse plug-in– came to my rescue. Grep console allows several regular expressions to be defined in the Eclipse console, highlighting the matching lines for easy reading.

I defined an initial regular expression to narrow in on some specific logging output related to the problem. After running the offending program, I could quickly scroll to potential problems in the thousands of lines of logging. From this logging I created an additional regexp of a different color containing the pointer value of interest.   This reduced the time to parse huge amounts of logging in search of a specific pointer value.

The one feature I was wishing for was the ability to jump to the next selected regular expression.  Even without it, this plug-in does one thing and does it well.

Design a site like this with WordPress.com
Get started