Tag Archives: eclipse

eclipse 3.6 (helios) – four good, 1 bad feature

Posted on by
1

Last summer, I wrote “eclipse 3.5 – four good, 1 bad feature“.  A year later and Eclipse 3.6 is out.   I didn’t try it earlier because I was busy with the SCEA part 1 and Core Spring 3 certifications.  While I may not be part of the official blogathon this time, I decided to use the same format as I did last year for Eclipse 3.5.  Another big difference is that I’ve only been using Eclipse 3.6 for a couple days this time.

Getting started

Quick install with favorite plugins:

My Eclipse 3.5 workspace was in a good state so I decided to use it for 3.6 development.  I did make a copy of it in case I wanted to go back to 3.5.  It wasn’t too time consuming to download/install “Eclipse IDE for Java EE Developers”.  The download was 206 MB, so I left that alone for a little while.  I also installed the plugins I use regularly as I wanted them installed before switching to do development in the new workspace.

  1. Sysdeo – For Tomcat with Eclipse.
  2. Ecl emma – For code coverage.
  3. PMD – For static analysis.
  4. Subversive – For Subversion connectivity.

Workspace setup:

None!  That’s right.  My settings were preserved.  Even settings for the plugins.  I was impressed with how smoothly this went.

Features

Favorite feature #1 – Subversive

The Subversive plugin was updated quite extensively with the Helios release train.  I have a lot to say on this so it is a whole other blog post.

Favorite feature #2 –Virtual Folders

Virtual folders are like a folder of shortcuts.  While you can’t put any “real” files under them, you can put other virtual folders and linked resources.  This has potential.  It means I can put related data together even if it lives in disparate places.

Favorite feature #3 – WORKSPACE_LOC

When you create a linked resource, you can define variables.  This has been the case in past releases too.  The difference is that you had to create a variable for the workspace location yourself.  Now it is built in.  Minor, yes.  But nice to not have to do.

Favorite feature #4 – Multiple quickfix

When writing Java code, “quick fix” is a convenient way to clean up your code.  Now if you have multiple instances of the same issue in a class, Eclipse offers to clean them all up at the same time.

And the worst feature

Code formatting. What happened? This used to work intuitively and well in Eclipse 3.4.  Yes 3.4.  You may have noticed it is my exact same pet peeve from Eclipse 3.5.  I was hoping they would fix it in Eclipse 3.6, but no such luck.  At least they introduce something new that bothers me more.

In Java, it gets rid of my careful placed (for readability) whitespace between lines. I checked the preferences and “number of empty lines to preserve” is set to one. HTML is much worse. If I format a bunch of lines containing one <input> per line, Eclipse turns this

<input type="hidden" name="action" value="moveAllSave" />
<input type="hidden" name="module" value="${moduleName}" />
<input type="hidden" name="source_forum_id" value="${sourceForumId}" />
<input type="hidden" name="log_type" value="0" />
<input type="hidden" name="log_description" value="bulk move from admin console">
into this
<input type="hidden" name="action" value="moveAllSave" /> <input
type="hidden" name="module" value="${moduleName}" /> <input
type="hidden" name="source_forum_id" value="${sourceForumId}" /> <input
type="hidden" name="log_type" value="0" /> <input type="hidden"
name="log_description" value="bulk move from admin console">

Huh? That didn’t happen before. I tried setting “never join lines” but it doesn’t take effect for HTML. I guess I’m not relying on the code formatting. Unfortunate as it will slow things down. But yuck. Just look at it.

Installing the Adobe AIR 2 SDK in Eclipse

Posted on by
2

While Adobe makes adding a new Flex SDK easy – just drop a new version folder alongside another version and point Eclipse to the new directory – they make installing a new Air SDK quite frustrating. The Air SDK is installed inside the Flex SDK, so to truly install a new version, you must hijack your existing Flex SDK and replace a few dozen files within the folder structure. It is my sincere hope that Adobe moves away from this coupling and allows Air SDKs to be more easily upgraded in the future without the need to piecemeal copy them onto an existing Flex SDK installation.

Below is short story of how I managed to get my application to build Adobe Air 2.0 applications with Eclipse and the steps I took to resolve the numerous issues that cropped up.

1. Download and Install the Air 2 Runtime and Air 2 SDK

The first step is to download the Air 2 runtime which installs itself within the operating system. The second step is to download the Air 2 SDK, which downloads as a zip file. Assuming you have Flex 2, 3, or 4 installed, there should be a plugin sdks directory that contains an AIR runtime folder such as:

Flex SDK root: C:\Program Files (x86)\Adobe\Flex Builder 3 Plug-in\sdks\3.2.0
Air Runtime root: C:\Program Files (x86)\Adobe\Flex Builder 3 Plug-in\sdks\3.2.0\runtimes

Backup (for safety) the runtimes folder and replace it with the one in the Air 2 SDK zip file. Congratulations, you have just installed the Air 2 SDK!

Note: You may have multiple Flex SDK folders on your computer with multiple versions. You should use whichever one your version of Eclipse is pointing to, or create a new version (“3.2.0-air2” for example), and point Eclipse to this new version.

2. Turning on Air 2 within your application

Next, try building and running your Air project within Eclipse using the Flash Builder plugin. Upon launching the compiled application, you will likely see the message “IIMEClient error”:

IIME Client Error

A little bit of digging, shows the error is caused by a combination of the following:

Flash Builder 4 + AIR 2.0 SDK + Application with AIR 1.5 app-descriptor

In short, the app-descriptor for my application (such myApplication.xml) requires that the namespace reference xmlns be changed from

http://ns.adobe.com/air/application/1.5
to http://ns.adobe.com/air/application/2.0

Once you change the version number, the application will compile and run without issue.

3. Full installation of Air 2 SDK required for Release Builds

While you can now build and run Air 2 applications within Eclipse, you will receive an error if you try to Export them as Release Builds. To resolve this issue you go back to step 1 and this time merge all of the files from your Air 2 SDK zip file onto your Flex SDK directory. This is especially risky, since you are replacing dozens of files throughout the SDK, so this time make sure to backup your entire Flex SDK folder. You should expand the zip file and replace over all files and folders.

For example, in the sub-directory bin replace two files from the Flex SDK: adl.exe and adt.bat, but leave the existing files in that folder in place. The rest of the files contained in the zip file should be used to replace the existing SDK files in a similar manner. Many operating systems offer a merge functionality that will only replace the files that have changed and keep the existing files in place.

After you are done, you can open a command window, navigate to the SDK bin folder and type “adt -version” to determine which version of Air is installed. My thanks to Michael Christoff for this part of solution that works on any OS.

The Result

Now you should be able to build, run, and release an Adobe Air 2 application. You can test this by exporting your Air Application to a .air release file, then installing your application using the Air 2 graphical runtime which was installed at the beginning of this process.

Where’s the Flex Plug-in for Eclipse 3.5?

Posted on by
8

Eclipse + Flex = X

Over 7 months after Eclipse 3.5 (Galileo) was released, Adobe still has not released an update for its popular Flex Builder 3 plug-in that would make it compatible with the most recent version of Eclipse. Those of us who rely on the plug-in for Flex/Air development are still stuck using Eclipse 3.4 (Ganymede), or trying a number of manual install attempts, described here and here, neither of which worked for me. Ultimately, though, I’m not fond of hacky solutions for production-level products that I pay good money for.

Adobe has informally acknowledged the issue via its bug-tracking system, FB-21284 and FB-21025 (login required), although they have not publicly announced when a solution will be available. With the planned release of Eclipse 3.6 (Helios) now less than 5 months away, it makes you wonder when and even if the issue will be addressed. The Flex/Air projects have always been one of Adobe’s more grass-root movements, especially compared to its Creative and Web Suite products, and it’s a shame they have let the developers down. I call on everyone to contact Adobe with your concerns about Flex, with the hope they will address the issue if they understand how many developers this affects.

Updated (September 2010): Since releasing Flash Builder 4, Adobe has updated the Flex Eclipse plug-in to support Eclipse 3.5. Unfortunately, Eclipse 3.6 came out in June 2010 and is currently not supported, so Adobe is already another version behind. Also, I recommend developers stick with Flex 3 for now, as the new version is quite cumbersome to work with, meaning you’ll have to stay with Eclipse 3.4 for the time being to develop Flex applications.