Highlight your Syntax

Now, summer is nearly over and I'm back on this blog. During summer time, I use to spend more time with my family (and doing vacation ;-) but now my head is full with lots of snippets that could make it into this blog.

First of all, I have integrated some syntax highlighting to these pages. This might be well-known and boring for you, but I didn't really know how to do this until finding Alex Gorbatchev's SyntaxHighlighter. It's purely based on JavaScript and hence can be easily integrated with lots of products, tools and engines – like Blogger.com. Integration couldn't be easier, see here for a step-by-step explanation.

When adding code, you just have to give your <pre> element a class like this: <pre class="brush:java">. That's it!

What do you get by this? Well, the well-known, nicely formatted code blocks like this one

public void prepareMethodOverrides() throws BeanDefinitionValidationException {
   // Check that lookup methods exists.
   MethodOverrides methodOverrides = getMethodOverrides();
   if (!methodOverrides.isEmpty()) {
      for (Iterator it = methodOverrides.getOverrides().iterator(); it.hasNext(); ) {
         MethodOverride mo = (MethodOverride) it.next();
         prepareMethodOverride(mo);
      }
   }
}

This works for lots of languages (called "brushes"), including XML and JavaScript, and you can easily provide a custom brush. Standard layout can be customized, of course, but the default is pretty good IMO.

There are just two or three things (there is always room for improvements ;-)

• Syntax Highlighter documentation is a bit sparse...
• The server hosting the CSS and JavaScript files, http://alexgorbatchev.com, seems to be not the fastest one. To speed up things, the Syntax Highlighter files could be hosted somewhere else, and they most probably already are.
• You can highlight particular lines using the <pre class="brush:java; highlight: [14, 15]"> syntax (see line 7 in example above). However, it seems you can't specify areas but have to list all individual lines which might be cumbersome.
  

All in all, pretty cool. Syntax Highlighter is open source under LGPL 3, but the author asks you to "buy him a beer" if you use his tool. Well, I honestly will think of some donation ;-)

Read More

Maven: How Relocated Artifacts Can Ruin Your Day

Wow, this is one of those days I struggle with issues all the time without actually going forward one little bit on my original task... I guess you all know this feeling :o(

Now, one of the things that I wasted quite some time on is excluding a dependency. One of our modules is defining a dependency to Apache DBCP framework like this:

<dependency>
  <groupId>commons-dbcp</groupId>
  <artifactId>commons-dbcp</artifactId>
  <version>1.2.1</version>
</dependency>

This dependency is transitively depending on some XML artifacts, which you can see by using the maven-dependency-plugin's tree goal:

...
[INFO] +- commons-dbcp:commons-dbcp:jar:1.2.1:compile
[INFO]   +- commons-pool:commons-pool:jar:1.2:compile
[INFO]   +- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO]   \- xerces:xercesImpl:jar:2.0.2:compile
...

Well, the xml-apis and xerces artifacts are a bit outdated and actually we didn't want them at all in our war files, so I decided to exclude them using the dependency exclusion feature:

<dependency>
  <groupId>commons-dbcp</groupId>
  <artifactId>commons-dbcp</artifactId>
  <version>1.2.1</version>
  <exclusions>
    <exclusion>
      <artifactId>xml-apis</artifactId>
      <groupId>xml-apis</groupId>
    </exclusion>
    <exclusion>
      <artifactId>xerces</artifactId>
      <groupId>xercesImpl</groupId>
    </exclusion>
  </exclusions>
</dependency>

What do you think will be the result? Surprisingly, xml-apis:xml-apis vanished, but xerces:xercesImpl didn't. The new dependency tree is the evidence:

...
[INFO] +- commons-dbcp:commons-dbcp:jar:1.2.1:compile
[INFO]   +- commons-pool:commons-pool:jar:1.2:compile
[INFO]   \- xerces:xercesImpl:jar:2.0.2:compile
...

That's strange, isn't it? It took me an hour or so playing around to find the reason for this behaviour: Xerces has been relocated with respect to its Maven coordinates... The only hint Maven is giving you is this message when executing in debug mode:

[DEBUG] While downloading xerces:xerces:2.0.2
  This artifact has been relocated to xerces:xercesImpl:2.0.2.

What does that mean? Well, you may relocate artifacts in the Maven repository when the group or artifact id should change (for more details, see the Guide to Relocation). Originally, the DBCP artifact specified a dependency to xerces:xerces in its dependencies – which you can see in the artifact's POM file (residing in your local Maven cache, for instance):

<dependency>
  <groupId>xerces</groupId>
  <artifactId>xerces</artifactId>
  <version>2.0.2</version>
</dependency>

However, xerces:xerces has been relocated to xerces:xercesImpl and these new coordinates are what is shown in the dependency tree. But, when excluding a dependency, you must specify the original transitive dependency (as defined by the artifact), not the new coordinates:

<dependency>
  <groupId>commons-dbcp</groupId>
  <artifactId>commons-dbcp</artifactId>
  <version>1.2.1</version>
  <exclusions>
    <exclusion>
      <artifactId>xml-apis</artifactId>
      <groupId>xml-apis</groupId>
    </exclusion>
    <exclusion>
      <artifactId>xerces</artifactId>
      <groupId>xerces</groupId>
    </exclusion>
  </exclusions>
</dependency>

How intuitive is that???

Maven should really do better, either by indicating the original coordinates when showing the dependency tree/list, or better yet by issuing a warning when trying to exclude a relocated dependency. I guess the latter one is not easy to implement, but current solution is just annoying!

Read More

Checkstyle: One and Only Configuration File?

The Checkstyle Challenge

When you are using both Eclipse and Maven, you are probably facing the same challenge like we do: you would like to have a single configuration file for Checkstyle tool and reference that in Eclipse as well as in Maven.

Checkstyle ships with some default conventions (according to the Sun coding standards). But you usually want to customize this and create your own configuration set, based on your corporate coding styles.

Now, you want to setup Checkstyle within Eclipse to provide direct feedback to developers. You want to setup Checkstyle with Maven to be able to have a coprehensive report built as part of your project site. And you want both to reference the same configuration file, to avoid having to maintain two of them. Naturally, right?

Well, unfortunately, it seems impossible to achieve... if you really found a way, let me know!

However, there nonetheless are some tips to help you having a centralized configuration of Checkstyle with both tools. This post is about how to do that.

Checkstyle with Maven

The goal is to centralize the Checkstyle configuration to make its usage as simple as possible for all the projects, avoiding manual configuration as far as possible. Fortunately, this is quite easy using Maven's dependency mechanism.

Essentially, we build a custom artifact that contains nothing but our Checkstyle configuration file. This JAR is deployed to the company's Maven repository from where it can be downloaded as a normal dependency when needed. After that, the Checkstyle plugin is configured (in the reporting section) to reference the packaged configuration file. That's it!

Now, we'll look at the details...

Let's assume our checkstyle configuration is located in config/my-checkstyle.xml. Then the POM of the checkstyle artifact, which actually is a minimal Maven project, looks like this:

  ...
  <groupId>com.fja.ipl</groupId>
  <artifactId>checkstyle-config</artifactId>
  <version>1.0</version>
  <build>
    <resources>
      <resource>
        <directory>config</directory>
      </resource>
    </resources>
  </build>
  ...

(Of course, you additionally have to add the distributionManagement section to be able to deploy the artifact, but this is usually derived by the company's base POM.)

Deploy the artifact. You'll notice that the created checkstyle-config-1.0.jar indeed contains your my-checkstyle.xml file in its root.

Now let's switch to the project that should use the Checkstyle report. The configuration file is referenced in the Checkstyle plug-in configuration in the reporting section like this:

  <reporting>
    <plugins>
      <plugin>
        <artifactId>maven-checkstyle-plugin</artifactId>
        <version>2.2</version>
        <configuration>
          <configLocation>my-checkstyle.xml</configLocation>
        </configuration>
      </plugin>
      ...
    </plugins>
  </reporting>

That is not yet working, Maven can't find this file – our checkstyle-config artifact has not been referenced. We do this now by adding it as an extension dependency to the POM as follows:

  <build>
    <extensions>
      <extension>
        <groupId>com.fja.ipl</groupId>
        <artifactId>checkstyle-config</artifactId>
        <version>1.0</version>
      </extension>
    </extensions>
    ...
  </build>

The artifacts configured as extensions will be included in the running build's classpath. That means, checkstyle-config-1.0.jar now is in the classpath of the Checkstyle plugin, and the file referenced by the configLocation setting is located in the JAR and hence can be found.

Using this approach, the Checkstyle configuration can be maintained centrally, and projects can get new versions simply by updating the artifact's version in the extension section.

Checkstyle with Eclipse

Unfortunately, I don't really see a way to use the same Checkstyle configuration, packaged into the Maven artifact, with Eclipse as well...

So you'll have to duplicate the configuration file. However, to keep the number of duplicates small, I recommend to put it on a central network drive within your company and use the Remote Configuration option of the Checkstyle Eclispe plugin to reference the remote file. This does not prevent you from working offline because Eclipse downloads and caches this file.

In this scenario, changing the Checkstyle configuration is done centrally by just updating the remote file. This is a great advantage over using a configuration that is part of the project, because in the latter case you would have to upgrade every single project.

Read More

Google and the Crystal Ball

Google brought us the Web Search. They brought us the Maps. They brought us their Mail, the News, the Images, the Videos... In other words, they revolutionized the web. They rule the web. You all know that.

They are so creative, cutting-edge and are always good for some surprise. Like this one: Google has announced the Wave project a few days ago, which indeed might have the power to turn into the "next generation of e-mail". Wave is a web based service platform designed to merge e-mail, instant messaging, wiki, and social networking. Gosh, this sounds exciting, really!

Yeah, Google is collecting data, probably more than we can imagine. And they will continue to do so. (A new study of UC Berkeley just revealed that Google is the dominant player in the tracking market; typically, tracking is done using "web bugs" that are embedded in the web page‘s HTML code, and are designed to enable monitoring of who is reading the page.)

But... aside from all discussions how evil or risky Google's data acquisitiveness might be, it opens a new world for something called "collective intelligence": discovering metadata based on the search engine data.

What does this mean? Well, Google records search phrases which can later be compared across specific regions, categories and time frames. Using Google's Insight for Search service, you can "see what the world is searching for". Pretty nice. For instance, search for "google wave" and see how the interest emerged end of May. Interestingly enough, there have already been a few searches in summer 2008!?!

Well, it even gets better. Google has found out that certain search terms used in their web search are good indicators of flu activity – when people have the flu, they search for symptoms, drugs etc. Google uses that to estimate flu activity on their Flu Trends page, and this indicator turns out to be quite good.

So, what is next? Possibilities seem endless, and Google will certainly surprise us again. Since they have all the data, and the (near) future is certainly hidden in that data – how about some kind of digital, web based crystal ball? I told you, so don't be surprised if they make it... ;o)

Read More

Eclipse Top Annoyances

Eclipse is one of those love/hate things. I love it and hate it, both at the same time.

The Love

Firstly, it's the best Java IDE on the market, and we successfully use it for years now. In the meantime, there might be other IDEs with an even richer feature set, better integration, nicer UI etc. but we actually don't care very much. I love Eclipse just for what it did to the Java and Open Source community, and it definitely has been pushing the edge for a couple of years now.

BTW, of course I know Eclipse is more than just a Java IDE, but this is my personal short interpretation of "development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle".

The Hate

Well, having said all this... sometimes Eclipse really drives me crazy. There are a couple of annoyances, some of them rather small but insistent, others bothering us since quite a long time.

The strange thing is, all of my complaints are not related to the more sophisticated plugins like Mylyn, WTP, MDT and so forth. (Yes, we use them too, albeit in a sketchy way.) No, the issues annoying me most are shown by the Platform or JDT, and maybe that's why they are actually so annoying.

The List

Okay, here is my list for Eclipse 3.4 (Ganymede):

6. Formatting

We have setup the Eclipse Java code formatter to match the project requirements. There are plenty of options to adjust to your needs, but... sometimes the algorithm is just broken. Take this example:

private Accumulator getSpecificAccumAndSetRuleDefaultValue(
                                                            CoverageRule calcStepRule,
                                                            CalculationStepInfo calculationStepInfo,
                                                            ...)
{
   ...
}

What is this extra line break before the first method argument good for? Instead of aligning the method arguments horizontally, Eclipse messed it up vertically. You can find several other strange formattings where formatted code requires extra space, mainly in long method or class declarations. Here is another example of an extra line break:

public class PersistenceService<R extends PersistentRootObject, D extends HibernateDaoSupport>
      implements
         IPersistenceService {
  ...
}

5. Blocking Workspace

I have blogged about this blocking behaviour before: sometimes, Eclipse can't save my file while it is building "in the background" and tells me that my "User Operation is Waiting"...

That's just silly, Eclipse should be able to do my save action at any time, if compiling or not. Loosing editor's content (by unintended editing, Eclipse crash or hang-up, whatever) just due to the impossibility to save is just not acceptable.

4. Startup Time

Depending on size of the workspace, you got to wait minutes before you can start editing. That's just too slow. Period.

3. Dialog Window Dimensions

When you open a project's Properties window, for instance, it will show up quite small. I have a large screen and don't like to scroll unnecessarily, so I resize the window to be considerably larger. However, the dialog dimensions are not persisted – when I close and reopen the same dialog, it shows up as small as before. Eclipse just refuses to remember what I like.

For other dialog windows (like Open Type), this works perfectly; why not for all of them?

2. Update Manager

I used to think the new Eclipse 3.4 update manager (p2 Provisioning System) was a good thing, but I'm no longer sure. As end user, you just don't want to mess around with features, dependencies, build numbers... and get strange error messages (see this post of an issue with a custom built Eclipse plugin we struggled with recently).

Additionally, the list of available software is too technical for most end users. Subversive SVN Connectors plugin provides 6 optional connectors, but at least one is required. So, which one(s) do I choose? Instead of having the full list with just the name and version strings, I would rather like to see some typical sets of required features ("typical installation" similary to when installing software on Windows). Alternatively, at least provide some end user level meta information like "This is the default feature", "Choose this item if..." etc.

1. Vanished Project Contents

Sometimes the content of my workspace projects in Package Explorer view is "gone", meaning I can't expand the project nodes any more. Yes, of course there is some content, and fortunately it is still on the disk – but just not showing up in the view.

Project Explorer view still shows the projects correctly. Closing and re-opening them in Package Explorer usually helps.

The Hope

I used to install the latest milestones for some years, but have given up this habit because of stability/quality/compatibility issues with Eclipse core and/or the plugins I use. Hence, I can't tell which ones will be addressed by the Eclipse 3.5 (Galileo) which is going to happen on 24th of June.

So... let's keep our fingers crossed!

Read More

Maven Plugin Releases: Do it yourself!

In my previous post, I have complained about Maven plugins that do not release new versions although there are blocking issues that are reported in Jira with patches attached to them. If you don't want to wait any longer for a new plugin release, just build one on your own. Here's how we usually do that.

Fix the Plugin

1. Checkout plugin sources from source repository and import as Eclipse project. The easiest way to do this is to use m2eclipse plugin's cool "Materialize Maven Projects" feature (see here).
2. Edit the POM and change the plugin's version number (see notes below).
3. Download the patch from the JIRA issue page.
4. Appy the patch using Eclipse: in project's context menu, select Team > Apply Patch...
5. Now build, unit-test and install the plugin using Maven.
6. Update your project's POM to use this new version, and test, test, test....
7. If everything is fine, upload your patched plugin to your repository manager to make it available to your team members.
8. Check in all changes you made, probably including the fixed plugin – into your repository, of course, not the plugin's one!

Give Some Thought to Version Numbers

A few rules on the fixed plugin's version string that have proven rational for us:

• You should not just increase the version number to prevent mix-up with future official versions of the plugin.
• Instead, we usually add a suffix made up of our company name and a consecutive number, like "-fja-1" for the first fix. This indicates the initiator and gives room for further fixes in case they should be required. Additionally, you always see the underlying official version. Example: <version>2.5-fja-1</version> for FJA's first fix of version 2.5.
• Don't change the plugin's group or artifact id because this would bypass Maven's version resolution, i.e. in Maven's eyes your fix would not just be a new version, but another plugin. You possibly end up having both plugins (the original one and your fix) configured in your builds, leading to duplicate execution and unexpected results.
• If you just change the version string, this can be done in the parent POM – you are locking down your plugins in your corporate/project root POM, do you? – making it easy to switch back to an official relase later... in case there is one available.

Read More

Maven Compromised by Plugins

Every piece of software has its flaws... The important part is how the project is dealing with bugs.

Maven is fine

With Maven, the situation actually is good enough: there have been releases of 2.0.x branch 1-2 times per year, to fix bugs and provide new features or improvements. At the same time, the 2.1.0 branch appeared with a milestone and a final release six month later.

However, you would usually not want to switch your Maven build system to a new version too often. This is always risky since a new version of the "core" may cause unexpected results in any area of the build. A continuous integration engine helps to detect bugs, but you never know.

Fortunately, Maven is heavily based on plugins – which means if you encounter any issue with a specific Maven task, it's usually caused by the related plugin, not the Maven core. That's great, right? You just upgrade your POMs to use a new version of the particular plugin. Better isolation, fewer risks!

(Some) Plugins are not!

But... this assumes that there is a new version of the plugin available. Now imagine this: a plugin has a bug reported by the community, and there is a Jira issue for that. Some brave soul even attached a patch to fix the issue and others confirmed that it works for them. Thus, the new bugfix release could easily be built. But what happens? No new release. Nothing. Not even an alpha/beta version. Not even a comment explaining why. For months!

Here are just two examples we stumbled upon the last couple of weeks:

• Javadoc plugin: The report is not generated at all for multi-module project if run from parent level and using the recommended aggregate goal. Jira issue reported 2008/08/18, patch added 2008/09/22. No new release ever since.


• Checkstyle plugin: Current version does not work with Checkstyle 5.0 that started to appear on the stage last summer. Jira issue created 2008/10/28, along with a patch; another patch added 2009/03/27. No new release ever since.

Wow. How annoying is that? There is a major/blocking issue, and there is a patch available, but the plugin owners don't take the time or effort to create a new release?!? Why so? What else could the community do to help fixing the plugin?

This way, the plugins are compromising usability of Maven. IMHO, that's a serious issue...

So, what can you do?

If you don't want to continue waiting for a new plugin release, you have to build one on your own, for your "private use". That's quite easy, fortunately, and I'll probably post about that later.

However, this is actually not what a typical Maven user wants to do. The plugins should just do it right: release more often to fix their known bugs! You could increase the pressure a little bit by voting for the Jira issue or adding some comments, but my experiences are not too good ...

Read More