Mylyn-Mantis connector 3.4.0 released

This release features an experimental rich text HTML editor, display of real names for comments and minor performance improvements to the task editor.

Rich text editor

The task editor was based on the plain-text contents of the task, which was sub-optimal when the task description contained HTML markup. Now there is an experimental setting in the task repository page which allows you to activate the rich text editor.

Be warned that it still has its kinks, and I’m putting this out for feedback rather than for mass consumption. It is expected that the formatting will not yet completely match the one from Mantis  and that some features such as highlighting incoming changes and dirty tracking are broken or require a nightly build of Mylyn.

That being said, this is a preview of the editor:

It is built on the excellent HtmlText component which arrived fresh with Mylyn 3.5.0 and features the exact HTML controls which are allowed by Mantis itself. I encourage you to report any bugs you find or improvements you need on the Mylyn-Mantis issue tracker. I hope that in a couple of releases this component will be stable enough to leave the experimental state.

Real names displayed for comments

Whenever available, the real names are displayed for comment authors.

Performance improvements

There was one more action which could freeze the task editor while opening, and it has been fixed. It especially affected repositories in offline mode.

Advertisement

Maven Recipe : GWT development profile

It’s no secret that I am a fan of GWT for web development. I believe it to be a superior solution for large-scale Javascript development. However, it does come with some downsides. Verbosity is one of them, but we have a solution for that – see how to cut down GWT’s verbosity. Another one is the long compilation time.  Since GWT generates permutations for multiple browser targets – 6 in version 2.1 – you will wait more than needed if you just need to compile for one browser.

It often is the case that a single-permutation application is deployed for smoke testing, and then a application with all permutations is deployed to Q&A. This is usually achieved by creating a development module which reduces the number of permutations to one. I will show you how to integrate this in a natural way into your Maven build.

I will start with the simplest possible Maven/GWT project, as shown below:

I will not insist over the contents of the project, as it is not important. The project only has one client-side class, and is based on the archetype from the excellent gwt-maven plugin from Codehaus.

In the pom.xml, the module to compile is configured to be the production one:

<plugin>
 <groupId>org.codehaus.mojo</groupId>
 <artifactId>gwt-maven-plugin</artifactId>
 <version>2.1.0-1</version>
 <!-- contents omitted -->
 <configuration>
  <!-- contents omitted -->
  <module>ro.lmn.maven.recipe.gwtdev.ProfileDemo</module>
 </configuration>
</plugin>

A compiler run currently generates six permutations and takes 23 seconds on my machine. I am lucky to have four cores at my disposal, but usually build server CPU time is scarce, so the effect is amplified.

robert@neghvar:~/git-repos/gwtdev-profile (master)> mvn clean package
...
[INFO] --- gwt-maven-plugin:2.1.0-1:compile (default) @ gwtdev-profile ---
[INFO] Compiling module ro.lmn.maven.recipe.gwtdev.ProfileDemo
[INFO]    Compiling 6 permutations
[INFO]       Compiling permutation 0...
[INFO]       Process output
[INFO]          Compiling
[INFO]             Compiling permutation 1...
[INFO]       Compiling permutation 2...
[INFO]       Compiling permutation 3...
[INFO]       Compiling permutation 4...
[INFO]          Compiling
[INFO]             Compiling permutation 5...
[INFO]    Compile of permutations succeeded
[INFO] Linking into /home/robert/git-repos/gwtdev-profile/target/gwtdev-profile-1.0-SNAPSHOT/ProfileDemo
[INFO]    Link succeeded
[INFO]    Compilation succeeded -- 22.702s
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 29.101s
[INFO] Finished at: Sat Mar 05 23:59:24 EET 2011
[INFO] Final Memory: 12M/142M
[INFO] ------------------------------------------------------------------------

To cut down on compilation time I will use a Dev module which compiles just for recent versions of FireFox:

<?xml version="1.0" encoding="UTF-8"?>
<module rename-to="ProfileDemo">
 <inherits name="ro.lmn.maven.recipe.gwtdev.ProfileDemo" />
 <set-property name="user.agent" value="gecko1_8" />
</module>

To select it in my pom.xml I will create a dev profile, which overwrites some of the configuration entries of the gwt-maven-plugin:

<profiles>
 <profile>
 <id>dev</id>
  <build>
   <plugins>
    <plugin>
     <groupId>org.codehaus.mojo</groupId>
     <artifactId>gwt-maven-plugin</artifactId>
     <configuration>
      <module>ro.lmn.maven.recipe.gwtdev.ProfileDemoDev</module>
      <draftCompile>true</draftCompile>
     </configuration>
    </plugin>
   </plugins>
  </build>
 </profile>
</profiles>

For added speed, I’ve enabled draft compilation, which means that the GWT compiler will spend less effort on trying to optimise the resulting javascript.

Rerunning the build with the -Pdev argument results in just one permutation being generated:

robert@neghvar:~/git-repos/gwtdev-profile (master)> mvn -Pdev clean package
...
[INFO] --- gwt-maven-plugin:2.1.0-1:compile (default) @ gwtdev-profile ---
[INFO] Compiling module ro.lmn.maven.recipe.gwtdev.ProfileDemoDev
[INFO]    Compiling 1 permutation
[INFO]       Compiling permutation 0...
[INFO]    Compile of permutations succeeded
[INFO] Linking into /home/robert/git-repos/gwtdev-profile/target/gwtdev-profile-1.0-SNAPSHOT/ProfileDemo
[INFO]    Link succeeded
[INFO]    Compilation succeeded -- 14.091s
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 19.939s
[INFO] Finished at: Sun Mar 06 00:08:55 EET 2011
[INFO] Final Memory: 11M/104M
[INFO] ------------------------------------------------------------------------

The speed saving is of 35% and will likely increase as the GWT code increases in size and complexity.

We have reached our goal of creating a GWT development profile. By using a Maven profile we can make minimal modifications to our configuration and even apply different compiler options.

The complete source code for this article is available at https://github.com/rombert/Maven-Recipe—GWT-development-profile. If you have any suggestions or corrections, please comment. Or better yet, fork me.

Cutting down GWT’s verbosity with gwt-mpv-apt

I am strong believer in GWT’s potential as a client-side web development solution. Its value proposition is quite exciting: write all your web code in Java, using tools of your choice, and the GWT compiler will output highly tuned, browser-compatible JavaScript. I use it whenever possible and never look back.

Still, there are some times when I feel that GWT’s programming style is too verbose ( see Reducing GWT custom widget verbosity ) to be really productive. I obviously save a lot of time, compared to what I would need to write a comparable interface using “plain” Javascript. But that does not mean that I’m happy to spend time writing code which in “real” Java would be much simplified using reflection. As there is no reflection ( java.lang.reflect ) support in GWT, I was stuck writing verbose code for event handling and DTOs.

That’s why I was thrilled to discover the gwt-mpv-apt project, which is a Java 6 annotation processor to help generate some of the boilerplate code involved in GWT projects. The setup is rather simple:

• Download gwt-mpv-apt.jar, put it in your project’s classpath
• In Eclipse, go to Project Settings, Java Compiler, Annotation Processing, and hit “Enable processing specific settings”. Go to Factory path and hit “Enable project specific settings”. Select the gwt-mpv-apt.jar, hit OK.
• For javac, use JDK6 and it will pick up the processor from your classpath automatically

To get a sense of what this can do for you, I’ll take the example of a GwtEvent which signals that a group of people arrived. The PeopleArrivedEvent should contain the count of people which arrived in this group, and their origin. In the screenshot below, the top editor shows what I wrote, and the bottom editor shows what was generated.  I collapsed the methods to make them all fit into one screen, but they are implemented.

gwt-mpv-apt has generated all the boilerplate code for us, and for an application which makes heavy use of events, this is a major time-saver.

Before going further, I must point out that this is based on an accepted Java standard – the Pluggable Annotation Processing API (JSR 269) – which is in my opinion one of the hidden gems in the Java Development Kit. The IDE support comes in for free, and as far as I know both Eclipse and NetBeans have good annotation processing support. In Eclipse, the annotation processor kicks in as soon as you save the file you’re working on and incrementally changes only the needed files. The integration with javac is also seamless – drop in the jar and it works.

Another good feature of this library is its error reporting: error markers are generated in the Eclipse editor just as they are reported to the compiler. This screenshot is an example of a wrongly named class, where the error marker is correctly placed on the class name:

The annotation processor currently has support for generating DTOs for gwt-dispatch and gwt-platform, and the savings are even more impressive. The left editor shows the code I wrote, while the right editors show the code which was generated. Even with folding enabled, I still can’t capture all the code.

I have shown how gwt-mpv-apt can help you reduce the amount of boilerplate code you write when working with GWT.  I encourage you to take it for a spin and let us know what you think about it. The project is still young, and it welcomes any contributions: feedback after usage, bug reports, testing, code contributions and spreading word are all appreciated. You can find more information at the GitHub project page, the GitHub issue tracker and the project mailing list.