A few months ago I griped that iTunes wouldn't let me delete a song from my collection while looking at a playlist. Turns out that's not exactly true -- it's just undocumented.

Marshall Robin dropped me a line to say that it indeed is possible to do it: just select the song(s) you want to delete and press Shift-Delete (alt/option-delete on Mac) and you'll be prompted to delete the track from the collection.

Thanks Marshall! Now I can get rid of all of those old singles in my collection by looking at a playlist I made of just those singles.

I released Durham 0.2.0 today, incorporating plugins and files from Eclipse 3.1. Durham's goal for 1.0 is to be effective metadata support for the Eclipse platform and Rich Client Platform (RCP) applications

Along with the Durham library, I also released the two proof-of-concept applications: AudioMan and QuickEditor. The best part about the release of these applications is that because of the RCP and my Ant build scripts I've released both applications on three platforms (Windows, Mac OS X and Linux) simultaneously.

Now that everything is set up I can continue to release these applications on all three platforms at the same time, which is an incredible advantage for an application developer. I do admit that the deployment setup took a good amount of work but RCP applications will really have an advantage in the future here, especially as non-Windows platforms like Mac OS X and Linux take up a larger share of the pie.

The Eclipse Rich Client Platform is very, very close to having very easy deployment, I think, and it will only get easier.

Now that deployment is taken care of, Durham 0.3.0 will include some necessary refactoring and new features. I will continue to demonstrate new Durham features with AudioMan and QuickEditor.

Here's an interesting issue that North Americans using Eclipse probably won't run into: Eclipse uses a different default file encoding for Windows, Linux and Mac OS X.

On Windows the default file encoding is a Windows-specific "standard" called Cp1252 which is actually a modified version of the ISO-8859-1 file encoding standard.

On Linux the default text encoding for files in Eclipse is UTF-8 (Unicode). I would have never have noticed this discrepancy if I didn't have variables with accented characters in them. I'm using these variables to create an enumeration class (pre-Java5) to represent a code standard for the most popularly used languages in the world: ISO 639-2.

I originally created this source file in Eclipse on Windows and it used the Cp1252 standard. The file was then checked into a CVS repository.

When I checked out the files in Eclipse on Linux (screenshot) I got this Eclipse compiler error:

Syntax error on token "Invalid Character"

I initially thought that Eclipse or Linux was at fault but after discovering the encoding difference (thanks to some prodding from #eclipse-dev) I changed my Windows copy of Eclipse to use UTF-8 for all editors and now all is well.

As I mentioned above, the default file encoding Eclipse on Mac OS X is also different: it uses a one byte Apple-specific file encoding scheme called MacRoman.

Why isn't Unicode being used by default across the board? Wouldn't that make cross-platform development easier? Using different default file encodings for each platform somewhat nullifies Java's cross-platform nature, no?

True, the differences between these encodings are small but they are enough to possibly cause people internationalization (I18N) problems down the line.

---

But that's not all. Changing Eclipse's file encoding to UTF-8 has some interesting consequences for my project's Ant build scripts. I had to specify that I'm using UTF-8 for the source files in the javac Ant task:

<javac compiler="javac1.4" encoding="UTF-8" debug="yes" srcdir="${src.dir}" destdir="${src-classes-debug.dir}">
   <classpath refid="compile-time.classpath"/>
</javac>

Otherwise the Ant javac task won't properly recognize the special characters and fail.

I was driving past the intersection of Somerset Street West and Queen Elizabeth Drive here in Ottawa and noticed some piles driven into the west side of the Rideau Canal.

I was curious so I got out of my car and saw more piles being driven in on the other side of the canal. It looks like the multi-million dollar footbridge from Centretown to the University of Ottawa is finally being built.

There's not a lot of room on the west side so the bridge cuts off the existing bike path there. It looks like it will go completely over the bike path on the east side of the canal.

It will be interesting to see how this affects the Centretown neighborhood east of Elgin Street. Right now it's a good walk (especially in the winter before or after the canal is frozen) to the university from Centretown. This bridge makes Centretown easily accessible from the school -- it could very well be the next Sandy Hill as far as students are concerned.

Durham has two proof-of-concept Rich Client Platform (RCP) applications to demonstrate its metadata support (AudioMan and Quick Editor). While using the Eclipse 3.1 milestones, I was still building/packaging/running these RCP applications from Eclipse 3.0.x plugins because they were more stable as a platform.

Now that Eclipse 3.1 is out, I want to move these RCP applications to RCP 3.1 plugins. There were a few new things and issues that I'll share here.

1. A lot of Eclipse 3.1 plugins are now distributed as completely contained JAR files. This makes them much easier to move around. Their internal structure has changed a bit: it's not just the old plugin directory structure JAR'd up (note: a JAR file uses the same compression as ZIP). There's no JAR-within-a-JAR. What if you wanted to extract the JAR back to a directory and make a slight modification, would that be possible? With the new structure it seems unlikely that it would work but I'm not sure. An upside is that these plugin JARs are harder to "corrupt" accidentally.

2. There's a new plugin in the RCP redistributable: org.eclipse.rcp. Right now there are no Java class files or extension points in this plugin, which leads me to suspect it's a placeholder. The only file of interest is about.ini, which contains some text for the About dialog in Help referring to the RCP platform.

3. One of the main RCP classes, WorkbenchAdvisor, has been split up in 3.1. The easiest way to see how this differs from 3.0 is to create a new Plug-in Project, select the Yes radio button for Rich Client Application and use the RCP application with a view template.

You'll notice ApplicationWorkbenchAdvisor uses two new classes ApplicationWorkbenchWindowAdvisor and ApplicationActionBarAdvisor. The WorkbenchWindowAdvisor handles the window-specific aspects of the workbench, like it's initial attributes and code to be run before and after it opens and closes. The ActionBarAdvisor handles action-related stuff formerly covered by methods like WorkbenchAdvisor.fillActionBars(). You'll notice that many WorkbenchAdvisor methods are now deprecated because of these changes, which doesn't leave much for the original WorkbenchAdvisor class to do.

4. The last problem I'm tackling is a major one: I can't get my RCP application to run with the 3.1. It seems like core.runtime isn't picking up the application id.

If I set the proper eclipse.product in config.ini I get the following error message:

!ENTRY org.eclipse.core.runtime 2005-07-11 04:37:50.440
!MESSAGE Product net.sf.durham.quickeditor.product could not be found.

!ENTRY org.eclipse.osgi 2005-07-11 04:37:50.480
!MESSAGE Application error
!STACK 1
java.lang.RuntimeException: No application id has been found.
{stack trace}

If I set the proper eclipse.application in config.ini I get the following error message:

!ENTRY org.eclipse.osgi 2005-07-11 04:48:07.36
!MESSAGE Application error
!STACK 1
java.lang.RuntimeException: Application "net.sf.durham.quickeditor.ui.QuickEditor" could not be found in the registry. The applications available are: <NONE>.
{stack trace}

Looking at how Eclipse 3.1 itself defines its application, I can't see where I'm going wrong. I haven't changed the product or application extension points at all and they worked just fine with 3.0.

I had to make a slight change in my config.ini file because I switched to using OSGi MANIFEST.MF files:

osgi.bundles=org.eclipse.core.runtime@2:start,
org.eclipse.update.configurator@3:start

I also replaced eclipse.exe and startup.jar with 3.1 versions but otherwise everything is the same. The fact that one of the above error messages says "The applications available are: <NONE>" makes me wonder if there may be a bug with core.runtime but I've probably just made a boneheaded mistake and missed something.

It's so frustrating to run into problems like this but I'll keep bashing on it.

Update 9:21 PM: I overlooked the Eclipse 3.1 Plug-in Migration Guide. Maybe it will help.

Tuesday 6:45 AM: Yep, boneheaded mistake. Remember that change to config.ini I mentioned above? See how it's split between two lines? Yeah, that's bad. I'm not sure why I split it like that but I think it's because when I looked at Eclipse's original config.ini file in Wordpad it was in a small window and as a result the line wrapped. D'oh!

Does config.ini need a validator of some sort? I realise now that when I wrapped that line above I violated the whole

[name]=[value]

pattern that an ini file follows. Eclipse could have told me about it in an editor and saved me some time chasing my tail. Isn't there already a property file editor for Eclipse? (I could be thinking of WTP). If so, why isn't it associated with ini files by default?

Also, I could have been given a better error message in the configuration log file when the application failed to start. Seems like having org.eclipse.update.configurator@3:start for osgi.bundles in config.ini is very important for 3.1, yet I had no idea and the error log certainly didn't help. That information could also be added to the 3.1 Plug-in Migration Guide FAQ.

At any rate my RCP apps work now so I'm happy as a clam.

Eclipse 3.1's new support for content types is already helping me out.

Durham has a lot of Ant build files, many of which don't have the default Ant build file name build.xml. In the past I had to associate each of these different filenames with the Ant editor in preferences, which was tedious.

Eclipse 3.1 looks at the file's contents, sees that its an Ant XML build file and associates the file with the Ant editor right out of the box. This is especially helpful with XML files because there are so many different file types with the extension xml.

Fannnnntastic. It's little things like this that save me loads of time in the long run. That's exactly what using an IDE is all about.

I'm moving the Durham project to Java 5.0 and not unexpectedly I've run into a few issues.

One of the issues was an error related to the junitreport Ant task. The task produces a nice HTML JUnit report from Ant's junit task output. Here's the error from the Ant log:

[junitreport] ERROR: 'Unrecognized XSLTC extension 'org.apache.xalan.xslt.extensions.Redirect:write''

I Googled the error and found a solution. It says to change any instances of
xmlns:redirect="org.apache.xalan.xslt.extensions.Redirect
to
xmlns:redirect="http://xml.apache.org/xalan/redirect" in XSL transforms that are being used.

Well, that's almost a solution. A developer is left to figure out which XSL file to edit in the case of junitreport. Here's what I found out.

The junitreport task uses a default XSL transform file to make the JUnit report but the transform can be overridden. The default transform file is located in [ant directory]\etc\junit-frames.xsl.

I wanted to change the default transform behaviour so that all of the Ant properties wouldn't be in the report. I was publishing these reports on the Internet and I didn't want sensitive information like passwords and machine specs in them.

I copied this file to my project and then specified its location when I called the junitreport Ant task:

<junitreport todir="${junit-data.dir}">
   <fileset dir="${junit-data.dir}">
      <include name="TEST-*.xml"/>
   </fileset>
   <report format="frames" styledir="${build.project.dir}" todir="${junit-reports.dir}"/>
</junitreport>

You use the styledir attribute to specify the directory of the custom junit-frames.xsl file.

The problem seems to be my custom XSL transform file; it's from an older version of Ant and doesn't have the xmlns:redirect correction explained above.

My solution was to recopy the junit-frames.xsl from the latest version of Ant (now 1.6.5) which has the xmlns:redirect correction and redo my custom changes in that file.

Incidentally, if you want to see how I removed properties from the JUnit report you can look at my custom junit-frames.xsl file by web browsing Durham's CVS repository on SourceForge.

For a variety of reasons I've decided to resume work on Durham and its proof-of-concept Rich Client Platform (RCP) products QuickEditor and AudioMan. Durham plugins provide metadata support for Eclipse plugins and RCP applications.

I'm not sure how long I'll continue to work on Durham but I have a few goals in the short term:

• Release Durham 0.1.0
• Move Durham to Eclipse 3.1
• Move Durham to Java 5
• Change Durham's metadata attribute key from a List of Objects to a unique string -- reverse URL like a Java package name
• Concurrent multi-platform releases of Quick Editor and AudioMan products

Rather than take a lot of focus away from the music-related project I'm working on, Durham should be comfortable and familiar territory that will keep me in the development loop.

Call it a psychological fake-out but I really need to be coding and releasing a real product right now. Durham 0.1.0 will be released very soon. Durham will probably take up 1/4 to 1/2 of my development time.

I don't think too many people will argue that good software solves a problem. Often the hard part is figuring out the exact problem that needs to be solved. In the software biz sometimes this is called requirements gathering, requirements analysis, domain research, etc.

After a month just thinking about it I've distilled an itch that needs scratching: a problem that probably needs some sort of software solution.

I can't keep track of all of the bands I like. I don't know when they release albums. I don't know when they are playing shows within a two hour drive of me (Ottawa or Montreal).

It's not even close. I can't even keep track of a dozen of my absolute favourites -- and want to be able keep up with over a hundred bands quickly and easily.

Why does this problem exist? The sources of information aren't arranged for the convenience of fans.

• Band websites cater to individual bands.
• Band mailing lists, while nicely proactive, inundate me with too much irrelevant email.
• Label websites try to sell the label's albums.
• Webzines (like PitchFork) are filled with advertising, snooty reviews and often concentrate on only one or two genres.
• Ticket sales websites cover a subset of venues/promoters in an area

The itch: Give me personalized relevant news about all of the bands I like all in one place.

I choose what types of news are relevant and what isn't. Only the bands I'm interested in. All genres in one site.

Scratch it.