eclipse 3.7 on the new mac – 8 good features & 1 bad + my plugin list

I downloaded Eclipse 3.7/Indigo release.  Since I got my Mac so recently, I waited to install development tools and create a new Mac workspace until Indigo came out.  My first set of installs on a Mac had some extra unexpected surprises of course.  Installing Postgres didn’t go nearly as smoothly as Eclipse.  Check back for the blog post on that!

Downloading

I went with the JavaEE developer release since it has web functionality built in.  I confirmed I had a 64 bit machine by running uname -a.  I also finally realized the clue that I’ve clicked download.  It’s that the download icon turns into a progress icon or changes the icon to my most recent download.

Installing

When I selected the download, it automatically unzipped it to downloads.  I then dragged it to the applications folder and added Eclipse to the dock as described.  Somehow I downloaded Helios instead of Indigo and had to do it again.  Not sure how that happened since I downloaded on Indigo release day.  I’ll assume I was tired.

Eclipse itself

My plugin install list contains what I used in Eclipse 3.6 plus a number of others.  This time I used Marketplace Client to try to get the plugins.  It’s nice that you can browse plugins and get ideas for things to install that you didn’t know about.  It’s not much easier to install, but it wasn’t exactly hard before.

Plugin Purpose Marketplace Experience
Sysdeo Tomcat integration Listed, but no install link. Still must install by unzipping into plugins directory.
EclEmma Code Coverage Smooth – click and install
PMD Static analysis Listed, but no install link. Had to use install site link directly.
Subversive To access Subversion repositories Smooth – click and install
eGit To access Git repositories (or run your own locally) Smooth – click and install
Hibernate Tools JPA assistance Did not install. There was a conflict with the built into JPA perspective in the JEE version of Eclipse. While I usually hand create my entities, I like having the plugin available but this isn’t a big deal.  The built into one appears to do the same thing.  And more likely, I wouldn’t use them either.
Groovy Groovy project/editor and console Couldn’t find in Marketplace, but think it is there.  Installed from install site link.
Freemarker IDE Freemarker syntax highlighting and macro assistance. Didn’t look in Marketplace.  I didn’t know this existed, but JBoss supplies it at the same URL as Hibernate Tools and I found it by accident.  Since JForum (CodeRanch) uses Freemarker, this could be helpful.  Trying it for five minutes, the syntax highlighting made the install worth it.
m2Eclipse Maven Smooth – click and install

What I like

In Eclipse 3.6, there were only 4 features I liked enough to remark upon.  This time, there are twice as many!

  1. A few versions of Eclipse ago if you had m.method(one, two) and tried to delete the “method” followed by autocomplete, it left the parenthesis and parameters alone.  Since at least Eclipse 3.5, it would add an extra set of parens and parameter templates.  Horribly annoying.  In Eclipse 3.7, it goes back to the original behavior.  Very excited about this fix!  This wasn’t reproducable, I think it was luck.
  2. JPA annotation autocomplete got better.  This is a minor convenience.
  3. Secure storage – passwords are now stored encrypted on disk.   This does mean anyone who uses your computer/account can commit on your behalf.  Not a problem on my home computer.
  4. “Document proxy icons in Cocoa” – you can drag an icon in the title bar to another application.  Sounds like it has potential.
  5. You can open the same file in different editors at the same time.  This is nice because I sometimes like to be in the visual and XML views.
  6. Being able to filter the compiler settings preferences.  (That list has grown so long it is hard to find specific options.)
  7. Compiler setting to ignore unavoidable generics problems (when calling legacy code.)  This is nice because it avoids false positives.  There is a risk because you have to be extra careful in that space, but I’ll find that in unit test.
  8. Paste URL into JUnit view – useful for loading an Ant or Maven junit report XML file from a nightly build.

And my worst feature

  1. The extract method keyboard shortcut is gone!  I use this one a lot.  It was there on Mac Eclipse 3.6.   You can still use the menus, but that is less efficient.

Mac Stuff

Since I had downloaded Eclipse 3.6 for the Mac, I installed it as well to see what was a Mac issue and what was an Eclipse 3.7 issue.  Here’s what is not new in Eclipse 3.7, but was new to me.

  1. In Safari, control left/right arrow take you the beginning/end of the line.  Which is convenient because shift + control + arrow highlights the line.   (I learned today that the command/apple key does the same as control although it is more awkward to type.)  In Eclipse, command left/right arrows takes you to the beginning/end of the line but control does not. Luckily, command + arrow does work in Safari so I’ll be using that shortcut now.  (It would be nice if there was a standard across applications for this – pgadmin doesn’t work the same way as either of these and I haven’t found the keyboard shortcut there yet.)
  2. My integration tests went down from three minutes to seven seconds!  This isn’t a Mac thing – it’s a six year old machine vs brand new machine.  But still cool.  I didn’t know they could run so fast.
  3. I changed the Mac system preferences to turn on “Use all F1, F2, etc keys as standard function keys”.  Having to press “fn” to use the debugger was quite annoying. I use the special keys a lot less than the function keys overall.  And when I am changing the sound volume, I’m not in the middle of typing/debugging.  I wish I could change it on only one of my two keyboards.  (I’m using a standalone keyboard where I care about the function keys being reversed.)  Not important, but it would be cool if I could switch to use the built in keyboard without the function key.

Liferay Standard Development Environment

I wrote a post a while back outlining the general set up we use when running our Liferay plugins through Continuous Integration, but it occurred to me that there should be an article that comes before that one which outlines the set up of the development environment. Many of the results of the decisions and best practices can be seen in that post, but there is still plenty that can be covered with respect to setting up a development environment for Liferay plugins.

Development Environments

There a few slight changes to the setup described in the previous article, but we’ll assume that a Liferay project always requires the following tools:

  • Liferay Development Studio (LDS). This is essentialy the Eclipse IDE plus some Eclipse plug ins to assist Liferay development.
  • Liferay Software Development Kit (SDK). This does most of the work with respect to building the plugins and the ANT tasks can be used from the command line without requiring the LDS.
  • A Liferay Bundle. A bundle is a pre-packaged Liferay server instance and in our case we tend to use Liferay bundled with Tomcat almost exclusively during development. The other benefit is that the Tomcat bundle is already assumed and pre-configured for some of the steps below and hence simplifies set up and reduces the work and chances of getting things wrong later.
  • Liferay Source. This isn’t essential to the set up, but when creating a new development environment we always do this at the same time and there or little additional effort required.

Recipe

Install Liferay Development Studio

You can install the LDS to the location of your choice and you can use the same LDS instance to manage multiple Liferay project workspaces, but more on this as we go. If you have already installed LDS then there is no need to do it again.

Create a new workspace directory for the Liferay project. For the sake of this article we’ll call the directory workspace.

Note that the Liferay source, SDK and bundle in the next steps should all be for the same version. Don’t mix them up. You have been warned.

Install Liferay Software Development Kit (SDK)

Copy the Liferay SDK zip file eg liferay-plugins-sdk-6.0-ee-sp1.zip to the workspace. Unzip the file so that there is a directory with the same name eg liferay-plugins-sdk-6.0-ee-sp1.

If your operating system does not allow soft links to directories, rename the SDK directory to plugins. Otherwise (and preferably) create a soft link to the SDK directory called plugins. By pointing external configuration at the plugins directory rather than at a specific SDK version, it makes it easier to upgrade your development environmnet later on.

Hopefully it gives you something like this in the workspace directory.

drwxr-xr-x 13      4096 2011-05-26 12:00 liferay-plugins-sdk-6.0-ee-sp1/
-rw-r--r--  1   9358463 2011-03-09 23:38 liferay-plugins-sdk-6.0-ee-sp1.zip
lrwxrwxrwx  1        71 2011-05-26 08:17 plugins -> liferay-plugins-sdk-6.0-ee-sp1/

Install the Bundle

Very similar to the previous step, copy the bundle zip file to the workspace, unzip and either rename or soft link as bundles. The bundles name is important here, so don’t get creative.

This adds the following to our directory:

lrwxrwxrwx  1        66 2011-05-26 08:18 bundles -> liferay-portal-6.0-ee-sp1/
drwxr-xr-x  5      4096 2011-05-26 16:32 liferay-portal-6.0-ee-sp1/
-rw-r--r--  1 187336800 2011-03-09 23:37 liferay-portal-tomcat-6.0-ee-sp1.zip

Install the Source

Once again copy the source zip file to the workspace directory, unzip and rename or soft link as source.

drwxr-xr-x 20      4096 2011-05-26 09:47 liferay-portal-src-6.0-ee-sp1/
-rw-r--r--  1 230320369 2011-03-09 23:37 liferay-portal-src-6.0-ee-sp1.zip
lrwxrwxrwx  1        70 2011-05-26 08:18 source -> liferay-portal-src-6.0-ee-sp1/

The complete Workspace

Remove the zip files if you want, but personally I just leave them there. The parts we’re interested in are the bundles, plugins and source directories.

lrwxrwxrwx  1        66 2011-05-26 08:18 bundles -> liferay-portal-6.0-ee-sp1/
drwxr-xr-x 13      4096 2011-05-26 12:00 liferay-plugins-sdk-6.0-ee-sp1/
-rw-r--r--  1   9358463 2011-03-09 23:38 liferay-plugins-sdk-6.0-ee-sp1.zip
drwxr-xr-x  5      4096 2011-05-26 16:32 liferay-portal-6.0-ee-sp1/
drwxr-xr-x 20      4096 2011-05-26 09:47 liferay-portal-src-6.0-ee-sp1/
-rw-r--r--  1 230320369 2011-03-09 23:37 liferay-portal-src-6.0-ee-sp1.zip
-rw-r--r--  1 187336800 2011-03-09 23:37 liferay-portal-tomcat-6.0-ee-sp1.zip
lrwxrwxrwx  1        71 2011-05-26 08:17 plugins -> liferay-plugins-sdk-6.0-ee-sp1/
lrwxrwxrwx  1        70 2011-05-26 08:18 source -> liferay-portal-src-6.0-ee-sp1/

How the parts interact

Before we complete the configuration, we’ll pause and look at how the parts interact.

Liferay Development Studio (LDS) and Software Development Kit (SDK)

The LDS provides some wizards, configuration checking and general assistance in building and managing Liferay plugins, but mostly it delegates to the SDK to perform the actual build and deploy work.

Therefore in just a second we’ll tell the LDS where the SDK is but first a word of warning…

Excuse me for shouting, but only ever register a single SDK with a Liferay workspace, and make sure it is the one in the workspace called plugins. Having multiple SDKs registered with in a single workspace can cause confusion or worse, and doesn’t add benefit to the environment. Please don’t do it.

LDS and the Bundle

LDS is able to start/stop the bundle but is also able to shortcut the deployment process and deploy straight to the bundle without needing help from the SDK.

Depending on the LDS version used, you may be asked to point to a bundle (or Liferay Runtime) the first time you point the LDS to a new workspace. Be sure to point to the workspace/bundles directory.

SDK and the Bundle

The SDK uses the libraries in the bundle to compile the plugins, and it also needs to know the location of the bunlde directory so that the deploy target can copy the WAR files to the Liferay Runtime

Configuration

As pointed out above, you should only configure a single SDK in the LDS for a given workspace. When you point the LDS to another workspace you are able to specify a different SDK as this value is configured against the workspace and is not global to the LDS. This will come as a major relief as the alternative would be incredibly restricting.

Furthermore, the plugins also have the registered name of the SDK included in their project properties, so it is important that all team members use the same name to describe the SDK within the LDS. I believe our default is liferay_sdk but it doesn’t matter what is selected provided everyone uses the same value. If not, you’ll be forced to fix this value every time someone else changes it in version control, and you’ll be unable to build or deploy until it is corrected. It is very annoying.

We may have already specified the Liferay Runtime when first pointing the LDS at the new workspace, but if not go to the LDS menu and select Window > Preferences and on the Preferences screen select Server > Runtime Environments, select ‘Add’, select the Liferay version for your bundle from the servers available and then point to the workspace/bundles/tomcat directory.

The next step would be to configure the SDK and bundle to work together, but as hinted earlier we don’t need to. If you look into the workspace/plugins/build.properties default settings, the server is already set to tomcat and the server location and deploy folder location are already correct because we have a directory called bundles pointing to the Runtime home directory.

Finally, right click on some spare space in the Package Explorer in the LDS, import, general, import and existing Eclipse project, navigate to the workspace directory, click OK and then select the source directory to import. This is useful for development and debugging.

Creating a new Plugin

When you create a new plugin project in the LDS, the wizard wants to know which SDK to use and since we have a single SDK there is no problem. The wizard ends up creating a new project in one of the subdirectories under the plugins directory, but within the LDS the project will display as if it were in the root directory of the workspace. It isn’t, but it is worth knowing the difference. If you get confused, right click the project in the LDS, go to the properties and look at the resource location.

Plugin Version Control

It is a bad idea to check the entire SDK into version control, so it is lucky that the LDS places them at the base of the Project Explorer. Right click, team, share, happiness.

Adding a Liferay plugin project from version control back into the LDS has some tricks to it.

Firstly, you’ll want to place the plugin project in the correct subdirectory in the SDK. When you import the project from version control, the second screen in the import wizard prompts you to import into the default workspace location. Don’t do this, and instead select the correct SDK subdirectory for that Liferay Plugin project type. But that’s not all.

Unless the bug has been fixed since the last time I checked, importing from version control will get the project into your LDS workspace, but the plugin will be imported as a Java project and not a Liferay Plugin Project; some of the Eclipse facets are lost. This matters. To fix it, right click and delete the project(s) that you just imported from version control but do not delete from the file system. Once again right click on some free space in the LDS Package Explorer, import, LIferay > Liferay Plugin SDK Projects, select the one and only SDK, select the project(s) to import and then they get imported correctly as Liferay Plugin projects.

Conclusion

So while I haven’t spelled out all of the learnings and reasons which has led us to this set up as our preferred Liferay Standard Development Environment, I hope that there are enough reasons provided for you to consider this approach and I hope that there are sufficient instructions provide to recreate the same in your own workspace.

git plugins for eclipse and netbeans

Last year, I tried out Git for the first time.  The command line was fine, but I really like my version control to be integrated into my IDE.

Overview

Git shines at some things.  Aside from the common ones, it is useful when internet access is unreliable.  We take connectivity for granted.

NetBeans

I hadn’t tried the NetBeans plugin last year. I mainly use Eclipse and only use NetBeans when working with a local robotics team. As such, I haven’t used NetBeans in eight months and needed to update it before I could try installing the NetBeans Git plugin.

Note: This Git plugin is in experimental mode. It will likely stay there as Oracle is working on an official plugin. Check Oracle’s page for updates. (Nice to see they didn’t abandon NetBeans after taking over Sun.)

The install procedure to connect to an existing repository:

  • Tools > Plugins
  • Select available plugins tab
  • Search for git
  • Click checkbox next to nbgit
  • Click install
  • Next and agree to license
  • Install
  • Continue to acknowledge it isn’t a signed/trusted plugin
  • Finish
  • Close
  • Team > Clone Other
  • Enter URL of git://github.com/prog694/frc
  • Enter directory/clone name if want to change. I had to change the clone name since the default was in use from last year’s Subversion project.
  • NetBeans looks for projects in that repository. I got a pop-up saying 7 projects were found and was asked to click “open project.” Select one or more projects to open them.

Eclipse

I tried egit again. This didn’t go well last year.  It’s now a year later and I’m on Eclipse 3.6 (Helios) instead of 3.5.  Things went much better this time around.

The install procedure to connect to an existing repository:

  • In Eclipse, connect to the update site.
  • Download all available plugins (egit and jgit).
  • Eclipse restarts
  • Change to the Git browsing perspective
  • Choose “clone Git repository”
  • Enter the URI.  In my case it was git://github.com/prog694/frc.  Note this same repository is available in a browser at https://github.com/prog694/frc.  All I did was change the protocol to git to connect. 
  • Since this repository is open for public browsing, I do not need to supply a username and password
  • Click next
  • Click next again to select the master
  • Click finish
  • Wait a minute or two
  • Expand until you find the project you want to checkout. (In this case, the actual project is a NetBeans project in this case so you can’t check it out as a project.  You can browse it in the repository view if you really want to check something.)

Conclusion

Both plugins are intuitive to use if you’ve a CVS/SVN plugin before.  Right click the project, choose “git” and the relevant option.  It’s nice to see the integration is seamless now.