Raible Designs

What's your preferred development infrastructure stack?

Over the years, I've used many different source control systems, wikis, bug trackers and continuous integration servers. On many projects, I've been responsible for recommending and helping to install these systems. For the most part, they've often been disparate, meaning there wasn't a whole lot of integration between the various applications. Here's a list of all the different systems I've used:

• Source Control Systems
  • CVS
  • StarTeam
  • Subversion
• Source Viewers
  • FishEye
  • Sventon
  • Trac
  • ViewVC
• Wikis
  • Confluence
  • MediaWiki
  • JSPWiki
  • Trac
• Bug Trackers
  • Bugzilla
  • JIRA
  • StarTeam
  • Trac
• Continuous Integration Servers
  • Bamboo
  • Continuum
  • CruiseControl
  • Hudson
• Mailing Lists / Forums
  • A private Google Group
  • Jive Forums
  • Mailman

I believe all of these applications are useful in supporting an efficient development process. When clients have asked me to help them build this type of infrastructure, I've often asked if they wanted to pay for it or not. If not, I'd recommend Trac (since it has a wiki, source viewer and bug tracker all-in-one) and Hudson. If they were willing to pay, I'd recommend the Atlassian Suite (Confluence, JIRA and Bamboo).

These stacks all seem to work pretty well and the Atlassian Suite certainly works great for AppFuse and other open source projects. However, I recently had the pleasure of working at Chordiant Software where we used Chordiant Mesh to collaborate and develop software. Their Mesh system is powered by Jive Clearspace and provides a wealth of tools for each project, including a dashboard, discussions, documents, notifications and widgets providing status + links to JIRA and Bamboo.

Even though Clearspace's rich text editor caused me some early frustration, I really enjoyed the fact that a solid development infrastructure existed. It made it much easier to collaborate, document and execute our development process. I realize that it's difficult to build and maintain a custom development infrastructure stack. Chordiant had a whole team that developed, enhanced and supported their environment. But that doesn't mean it's impossible and not worth striving for.

I think there's a number of best-of-breed applications you can use to build a sweet development infrastructure stack.

• Source Control: Git
• Source Viewer: FishEye
• Wiki: Jive SBS
• Bug Tracker: JIRA
• Continuous Integration: Hudson

I've only used Git for a few weeks, but I can easily tell it's better than Subversion. I don't think it's easy to convince companies to switch their source control system, so it's probably not worth arguing if you're already using Subversion. I can also envision using Confluence instead of Jive SBS, but then you lose forum support and have to use something like Mailman or Google Groups. JIRA Studio looks close to my dream stack, except it doesn't support Git or a forum + mailing list system.

What is your preferred development infrastructure stack? Why?

A Letter to the AppFuse Community

The last AppFuse release was way back in May 2008. Many folks have asked when the next release would be ever since. Often, I've said "sometimes this quarter", but obviously, that's never happened. For that, I apologize.

There are many reasons I haven't worked on AppFuse for the past 18 months, but it mostly comes down to the fact that I didn't make time for it. The good news is I'm working on it again and will have a release out sometime this month. Unfortunately, it probably won't be a 2.1 final release, but there's so many things that've changed, I feel like a milestone release is a good idea. Here's a brief summary of changes so far:

• Changed archetypes to include all source and tests for the "webapp" portion of the application. No more warpath plugin, merging wars and IDE issues. Using "mvn jetty:run" should work as expected.
• Moved from Spring XML to Annotations.
• AppFuse Light converted to Maven modules and now depends on AppFuse's backend.
• Published easier to use archetype selection form in the QuickStart Guide.
• Published archetype selection form for AppFuse Light. I do plan on combining these forms as soon as I figure out the best UI and instructions for users to choose AppFuse or AppFuse Light.
• Upgraded all libraries to latest released versions (Spring 3 hasn't had a final release yet).
• Upgraded to Tapestry 5 thanks to Serge Eby. I still need to complete tests and code generation for tests.
• Added Compass support thanks to a patch from Shay Banon.
• Upgraded from XFire to CXF for Web Services.
• Moved Maven repository to Sonatype's OSS Repository Hosting for snapshots and releasing to Maven Central. There are no longer any AppFuse-specific artifacts, all are available in central.

I realize there's many full-stack frameworks that do the same thing as AppFuse with less code. Examples include Ruby on Rails, Grails, Seam, Spring Roo and the Play framework. However, there seems to be quite a few folks that continue to use AppFuse and it stills serves the community as a nice example of how to integrate frameworks. Furthermore, it helps me keep up with the latest framework releases, their quirks and issues that happen when you try to integrate them. In short, working on it helps me stay up to speed with Java open source frameworks.

For those folks that like the 1.x, Ant-based version of AppFuse, there will not be a 1.9.5 release. I know I promised it for years, but it's simply something I will not use, so I'd rather not invest my time in it. I'm sorry for lying to those that expected it.

So what's the future of AppFuse? Will it continue to integrate web frameworks with Spring and popular persistence frameworks? Possibly, but it seems more logical to align it with the types of Ajax + REST applications I'm creating these days. I'm currently thinking AppFuse 3.0 would be nice as a RESTful backend with GWT and Flex UIs. I might create the backend with CXF, but it's possible I'd use one of the frameworks mentioned above and simply leverage it to create the default features AppFuse users have come to expect.

More than anything, I'm writing this letter to let you know that the AppFuse project is not dead and you can expect a release in the near future.

Thanks for your support,

Matt

Running Hosted Mode in GWT Libraries (when using Maven)

Earlier this year, I wrote about Modularizing GWT Applications with GWT-Maven. Fast forward 8 months and I'm still working with GWT and using this same technique. However, this time I'm working with the Maven GWT Plugin from Codehaus. In my last post, I wrote:

The results of modularizing your application are beneficial (shared code) and detrimental (you have to mvn install gwt-core whenever you make changes in shared classes). If you know of a way to configure the gwt-maven plugin to read sources from both gwt-core and gwt-webapp in hosted mode, I'd love to hear about it.

The good news is I found a solution for this, using the Builder Helper Maven Plugin. The GWT Maven Plugin's Productivity tip for multi-project setup has more information on how to configure this (note: we use IntelliJ and Eclipse on my project and did not need to configure this in a profile).

All was fine and dandy with this configuration until I wanted to be able to run hosted mode to develop/test everything in my library before including it in my main project. Luckily, you can still run mvn gwt:run on a JAR project. However, when you configure your pom.xml so sources are included in your JAR, you run into an issue: your *.java files will be copied to war/WEB-INF/classes and hosted mode will use these files as source rather than the ones you're editing in src/main/java.

To solve this, I changed my pom.xml to do two things:

• Only copy resources right before packaging (in the test phase).
• When packaging is complete, delete the *.java files from war/WEB-INF/classes (using Ant).

Below is the XML I used to make this possible. Please let me know if you have a way to simplify this configuration.

<plugin>
    <artifactId>maven-resources-plugin</artifactId>
    <version>2.4.1</version>
    <executions>
        <execution>
            <phase>test</phase>
            <goals>
                <goal>copy-resources</goal>
            </goals>
            <configuration>
                <outputDirectory>${project.build.outputDirectory}</outputDirectory>
                <resources>
                    <resource>
                        <directory>src/main/java</directory>
                    </resource>
                    <resource>
                        <directory>src/main/resources</directory>
                    </resource>
                </resources>
            </configuration>
        </execution>
    </executions>
</plugin>
<plugin>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.3</version>
    <executions>
        <execution>
            <phase>package</phase>
            <goals>
                <goal>run</goal>
            </goals>
            <configuration>
                <tasks>
                    <delete>
                        <fileset dir="${project.build.outputDirectory}" includes="**/*.java"/>
                    </delete>
                </tasks>
            </configuration>
        </execution>
    </executions>
</plugin>

This solution seems to work pretty well. As far as developing your library in hosted mode, you'll need to configure two *.gwt.xml files, one that doesn't have an <entry-point> defined and one that does. Configure the one with the entry point as the <module> in your gwt-maven-plugin configuration.

As a side note, I found a few issues with the 1.1 version of the Maven GWT Archetype. Below are the steps I used to fix these issues and upgrade to GWT 1.7.0 (I realize 1.7.1 is out, but gwt-dev-1.7.1-mac.jar doesn't exist in Maven central).

First, create a new project by running the following from the command line:

mvn archetype:generate \
  -DarchetypeGroupId=org.codehaus.mojo \
  -DarchetypeArtifactId=gwt-maven-plugin \
  -DarchetypeVersion=1.1 \
  -DgroupId=com.yourcompany \
  -DartifactId=gwt-project -Dversion=1.0-SNAPSHOT -B

After creating the project, you'll need to modify the pom.xml as follows:

1. Change the gwt-maven-plugin's version to 1.1.
2. Change the ${gwtVersion} property to 1.7.0.
3. Add <runTarget>Application.html</runTarget> to the <configuration> element of the plugin.
4. Move Application.html and web.xml so they're under the "war" directory.
5. Update Application.html to prepend the GWT module name in the <script> tag.

I hope these instructions help you create modular GWT projects with Maven. This setup is working great on my current project.

How to use GWT 2.0 with Maven and Generate SOYC Reports

One of the most interesting features coming in GWT 2.0 is code splitting and the ability to use GWT.runAsync() to reduce the size of your application's initial download. This week, I learned how to use GWT 2.0 with my GWT 1.6/Maven project. Below are instructions on how to build and use the latest GWT with Maven.

• Checkout GWT and setup GWT_TOOLS.
• Set a GWT_VERSION environment variable to 2.0.0-SNAPSHOT (export GWT_VERSION=2.0.0-SNAPSHOT).
• Build GWT with the ant command.
• After building completes, install the GWT artifacts into your local Maven repository using the following commands:

  mvn install:install-file -DgroupId=com.google.gwt \
  -DartifactId=gwt-user -Dversion=2.0.0-SNAPSHOT \
  -Dpackaging=jar -Dfile=build/lib/gwt-user.jar
  
  mvn install:install-file -DgroupId=com.google.gwt \
  -DartifactId=gwt-servlet -Dversion=2.0.0-SNAPSHOT \
  -Dpackaging=jar -Dfile=build/lib/gwt-servlet.jar
  
  mvn install:install-file -DgroupId=com.google.gwt \
  -DartifactId=gwt-dev -Dversion=2.0.0-SNAPSHOT \
  -Dclassifier=mac -Dpackaging=jar -Dfile=build/lib/gwt-dev-mac.jar
  
  mkdir temp
  tar -zxf build/dist/gwt-mac-2.0.0-SNAPSHOT.tar.gz -C temp
  cd temp/gwt-mac-2.0.0-SNAPSHOT
  zip -0 gwt-mac-2.0.0-SNAPSHOT.zip lib*.jnilib
  cd ../..
  
  mvn install:install-file -DgroupId=com.google.gwt \
  -DartifactId=gwt-dev -Dversion=2.0.0-SNAPSHOT \
  -Dclassifier=mac-libs -Dpackaging=zip \
  -Dfile=temp/gwt-mac-2.0.0-SNAPSHOT/gwt-mac-2.0.0-SNAPSHOT.zip
  

  Thanks to Jason for his help with this script.
• Modify the pom.xml of your GWT project to use the the gwt-maven-plugin from Codehaus. Of course, you'll need to modify the <runTarget> to fit your project.

  <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>gwt-maven-plugin</artifactId>
      <version>1.1</version>
      <configuration>
          <runTarget>org.appfuse.gwt.mvc.${entry.point}/${entry.point}.html</runTarget>
      </configuration>
      <executions>
          <execution>
              <goals>
                  <goal>compile</goal>
                  <goal>test</goal>
              </goals>
          </execution>
      </executions>
  </plugin>
  

• Modify your dependencies to match the ones below. With the Codehaus plugin, dependencies are much more concise.

  <dependency>
      <groupId>com.google.gwt</groupId>
      <artifactId>gwt-servlet</artifactId>
      <version>${gwt.version}</version>
      <scope>compile</scope>
  </dependency>
  <dependency>
      <groupId>com.google.gwt</groupId>
      <artifactId>gwt-user</artifactId>
      <version>${gwt.version}</version>
      <scope>provided</scope>
  </dependency>
  

• Add <gwt.version>2.0.0-SNAPSHOT</gwt.version> to the properties section of your pom.xml.
• At this point, you should be able to compile your project with mvn gwt:compile and run it in hosted mode using mvn gwt:run.

Generate SOYC Reports
In Google's code splitting documentation, it mentions The Story of Your Compile (SOYC). From the documentation:

To obtain a SOYC report for your application, there are two steps necessary. First, add -soyc to the compilation options that are passed to the GWT compiler. This will cause the compiler to emit raw information about the compile to XML files in an -aux directory beside the rest of the compiled output. In that directory, you will see an XML file for each permutation and a manifest.xml file that describes the contents of all the others.

The second step is to convert that raw information into viewable HTML. This is done with the SoycDashboard tool.

The first step is not currently possible with the gwt-maven-plugin, so I created a patch for it.

If you patch the gwt-maven-plugin and install it locally, make sure and change the version in your pom.xml to 1.2-SNAPSHOT.

To use the SoycDashboard tool, you'll need to install the gwt-soyc-vis.jar.

mvn install:install-file -DgroupId=com.google.gwt \
-DartifactId=gwt-soyc-vis -Dversion=2.0.0-SNAPSHOT \
-Dpackaging=jar -Dfile=build/lib/gwt-soyc-vis.jar

Now you can generate SOYC reports with mvn gwt:compile -Dgwt.compiler.soyc=true. You can also add <soyc>true</soyc> to the <configuration> section of the gwt-maven-plugin.

The second step (converting the raw information into viewable HTML) is possible using java from the command-line, or by using the exec-maven-plugin. Here's the (lengthy) command-line version:

java -Xmx1024m -cp /Users/mraible/.m2/repository/com/google/gwt/gwt-soyc/2.0.0-SNAPSHOT/gwt-soyc-2.0.0-SNAPSHOT.jar:/Users/mraible/.m2/repository/com/google/gwt/gwt-dev/2.0.0-SNAPSHOT/gwt-dev-2.0.0-SNAPSHOT-mac.jar com.google.gwt.soyc.SoycDashboard -resources ~/.m2/repository/com/google/gwt/gwt-soyc/2.0.0-SNAPSHOT/gwt-soyc-2.0.0-SNAPSHOT.jar -out target/soyc-report target/extra/org.appfuse.gwt.mvc.MVC/soycReport/stories0.xml.gz target/extra/org.appfuse.gwt.mvc.MVC/soycReport/dependencies0.xml.gz target/extra/org.appfuse.gwt.mvc.MVC/soycReport/splitPoints0.xml.gz

In this example, I'm using the files from stories0.xml.gz, dependencies0.xml.gz, splitPoints0.xml.gz. In the soycReport output directory, there's 5 of each these files and I'm not sure what the difference between reports is. Hopefully someone on the GWT team can elaborate. The exec-maven-plugin version is as follows:

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>exec-maven-plugin</artifactId>
    <version>1.1</version>
    <configuration>
        <executable>java</executable>
        <arguments>
            <argument>-cp</argument>
            <argument>
                ${settings.localRepository}/com/google/gwt/gwt-soyc/2.0.0-SNAPSHOT/gwt-soyc-2.0.0-SNAPSHOT.jar:${settings.localRepository}/com/google/gwt/gwt-dev/2.0.0-SNAPSHOT/gwt-dev-2.0.0-SNAPSHOT-${platform}.jar
            </argument>
            <argument>com.google.gwt.soyc.SoycDashboard</argument>
            <argument>-out</argument>
            <argument>target/soyc-report</argument>
            <argument>-resources</argument>
            <argument>
                ${settings.localRepository}/com/google/gwt/gwt-soyc/2.0.0-SNAPSHOT/gwt-soyc-2.0.0-SNAPSHOT.jar
            </argument>
            <argument>${project.build.directory}/extra/org.appfuse.gwt.mvc.MVC/soycReport/stories0.xml.gz</argument>
            <argument>${project.build.directory}/extra/org.appfuse.gwt.mvc.MVC/soycReport/dependencies0.xml.gz</argument>
            <argument>${project.build.directory}/extra/org.appfuse.gwt.mvc.MVC/soycReport/splitPoints0.xml.gz</argument>
        </arguments>
    </configuration>
</plugin>

After configuring this plugin in your project, you should be able to run mvn gwt:compile exec:exec and open the generated report (at target/soyc-report/SoycDashboard-index.html). Currently, there doesn't seem to be much documentation on SOYC. Fred Sauer's recent presentation talks a bit about SOYC and GWT.runAsync(), but that's about it.

To figure out how to use GWT 2.0 with Maven, I used my GWT MVC Example project. The first SOYC report I generated said the initial download was 108,967 KB. To integrate GWT.runAsync(), I modified all the project's controllers so their handleEvent() methods changed from this:

public void handleEvent(AppEvent event) {
    onViewHome(event);
}

To this:

public void handleEvent(final AppEvent event) {
    GWT.runAsync(new RunAsyncCallback() {
        public void onFailure(Throwable throwable) {
            Window.alert(throwable.getMessage());
        }

        public void onSuccess() {
            onViewHome(event);
        }
    });
}

When I generated a new SOYC report, the initial download size was reduced to 56,718 KB. Furthermore, I was able to see that my "Leftovers code" consisted of 63,175 KB. I'm sure there's better ways to split my project using GWT.runAsync(), but I'm happy to see I was able to reduce the initial download by 50%.

If you'd like to try GWT 2.0, you can can download my gwt-mvc example project. To build/run this project, you'll need to 1) build and install GWT, 2) patch gwt-maven-plugin and 3) run mvn gwt:compile exec:exec to generate the SOYC report. In an ideal world, the gwt-maven-plugin can be enhanced to generate the SOYC report (rather than using the exec-maven-plugin). In the meantime, I think it's pretty cool that you can try out GWT 2.0 features while they're still being developed.

Testing GWT Applications

Last week, I did some research on GWT, how to test it and code coverage options for tests that extend GWTTestCase. The reason I did this is because I've found that most of the GWT tests I write have to extend GWTTestCase and I'd like to have code coverage reports. Read below for more information on my findings for testing GWT classes.

There are quite a few articles about testing GWT applications. Here are a few samples:

• Test-First GWT
• Test driven development for GWT UI code
• Test driven development for GWT UI code with asynchronous RPC
• Enabling Test Driven Development in GWT client code
• JUnit tests for widgets - thread about which components to test.

The main gist of these articles is that you should structure your code to make the core functionality of your application testable without having to depend on GWTTestCase.

All of them also advocate using an MVC or MVP (Model View Presenter) pattern. Currently, I'm using GXT and its MVC Framework. Unfortunately, GXT's MVC doesn't have much documentation. The good news is there is a good article that explained enough that I was able to refactor my project to use it.

The unfortunate side of this refactoring was I discovered that classes that extend GXT's MVC Framework have to be tested with GWTTestCase. The downside to extending GWTTestCase is there is it's difficult to create code coverage reports.

GWT's issue 799 has some patches that should make code coverage possible. I tried to implement code coverage with Eclipse and EclEmma using this README, but failed. In the process, I discovered an issue with Eclipse 3.4 and JUnit on OS X. Reverting to Eclipse 3.3 solved this problem, but I was still unable to make EclEmma work with GWT.

After failing with Eclipse, I tried to use the emma-maven-plugin. I was also unable to get this to work, with my findings documented in this thread.

Finally, I did have some luck with getting IDEA's built-in code coverage feature working. However, after getting it to work once, it failed to work for the rest of the day and I haven't had success since.

Code Coverage and GWT
Because of these issues with GWT 1.5 and code coverage, I think I'll wait until GWT 1.6 to worry about it. The good news is 1.6 M1 was released last Friday. If continuing to use GWTTestCase becomes an issue, I may write my own MVC Framework that doesn't use classes that call native JavaScript. Hopefully GXT MVC's framework will provide a good example.

In addition to trying to get code coverage working, I used the internets to figure out how run GWT tests inside of Eclipse and IDEA. I don't remember the resources I used, but hopefully this up-to-date documentation will help others. The nice thing about using an IDE to run these tests is they typically execute much faster.

Running GWT Tests in Eclipse
You should be able to run most of your GWT tests from within Eclipse using the following steps.

1. Right-click on a test that extends GWTTestCase and go to Run As > JUnit Test. It's likely you will see the error message below.

   Invalid launch configuration: -XstartOnFirstThread not specified.
   
   On Mac OS X, GWT requires that the Java virtual machine be invoked with the
   -XstartOnFirstThread VM argument.
   
   Example:
     java -XstartOnFirstThread -cp gwt-dev-mac.jar com.google.gwt.dev.GWTShell
   

2. To fix this error, go to Run > Open Run Dialog. Click on the Arguments tab and add the following values. The 2nd value is to increase the amount of memory available to the test and avoid an OOM error.

   -XstartOnFirstThread -Xmx512M

3. When you re-run the test, you will probably see the following error:

   com.google.gwt.junit.JUnitFatalLaunchException: The test class 'org.richresume.client.home.HomeControllerGwtTest' 
   was not found in module 'org.richresume.client.Application'; no compilation unit for that type was seen
     at com.google.gwt.junit.JUnitShell.checkTestClassInCurrentModule(JUnitShell.java:193)
     at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:628)
     at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:150)
     at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:219)
   

4. To fix this, open the Run Dialog again, click on the Classpath tab and click on User Entries. Click on the Advanced button and select Add Folders. In the Folder Selection dialog, select your source and test directories (e.g. src/main/java and src/test/java).
5. Run the test again and you should see a green bar in your JUnit tab.
6. To create a JUnit configuration that runs all tests, duplicate the previously mentioned run configuration. Then change the name to "All Tests" and select the 2nd radio button to run all tests in the project.
7. Click Run to execute all the tests in the project.

Running GWT Tests in IDEA
You should be able to run your GWT tests from within IDEA using the following steps.

1. Right-click on a test that extends GWTTestCase and go to Run "TestNameGwtTes...". It's likely you will see the error message below.

   Invalid launch configuration: -XstartOnFirstThread not specified.
   
   On Mac OS X, GWT requires that the Java virtual machine be invoked with the
   -XstartOnFirstThread VM argument.
   
   Example:
     java -XstartOnFirstThread -cp gwt-dev-mac.jar com.google.gwt.dev.GWTShell
   

2. If you get a compiler error instead, you may need to add the GWT Facet to your project. To do this, right-click on your project's top-most folder in the left pane. Select Module Settings > Facets and enable GWT for your module.
3. To fix the -XstartOnFirstThread issue, go to Run > Edit Configurations. Add the following values to the VM Arguments field. The 2nd value is to increase the amount of memory available to the test and avoid an OOM error.

   -XstartOnFirstThread -Xmx512M

   NOTE: If you still get a compiler error, see this page for a possible solution.
4. Run the test again and you should see a green bar in your Run tab.
5. To create a JUnit configuration that runs all tests, duplicate the previously mentioned run configuration. Then change the name to "All Tests" and change the Test configuration to search for tests in the whole project.
6. Run the new configuration to execute all the tests in the project.

Testing GWT applications isn't as straightforward as writing JUnit tests, but I do believe it's getting better. If you have any additional tips and tricks, please let me know.

AppFuse Light » AppFuse, Maven Archetypes and Shared Web Assets

Last night, I stayed up into the wee hours of the morning working on something I've been wanting to do for a long time. It wasn't until I was trouncing around the woods in Montana that I realized how easy it would be. The something I've wanted to do was to modify AppFuse Light to use AppFuse's core modules (service and dao). It only took me a few hours to make it happen and it inspired additional ideas.

I believe the major mistake we made in AppFuse 2.x was making it easy for user's to upgrade their applications. We currently use the maven-war-plugin and our own maven-warpath-plugin to make it possible to include AppFuse classes and assets in your project. You can easily start a new project w/o having a whole bunch of files in your project. The problem is, you can't easily use "mvn jetty:run" to work on your project. Of course, you can use "mvn appfuse:full-source" to solve this, but I'm starting to think more and more that "full-source" should be the default. This is what we did in 1.x and it seems to be the more natural pattern for folks using AppFuse.

That hard part about moving to "full-source" by default is coming up with a way to share common assets and classes among wars and war projects. Sure, I can copy all the shared images, css and js into each project - but that could become a maintenance nightmare. Subversion 1.5 with relative svn:externals might solve this, but it still seems kinda hacky. I don't want to use the maven-war-plugin because the overlay is kinda hokey and I think it's easier for users to understand when everything is in their project. AppFuse's current directory structure in SVN looks as follows. I've added indicators of what is in each directory.

Rather than using AppFuse's current (manual) archetype-creation process, I'd like to move to a more automated creation process using the maven-archetype-plugin's create-from-project feature. I'd like to figure out a way where I can have the source code and assets from web/common included in each of the other web/* projects (both when using "jetty:run" and "archetype:create-from-project"). One idea I thought of is to make Jetty/Maven aware of multiple src/war directories for "jetty:run" and "package" and then somehow hook into the archetype plugin at creation time to pull in the shared resources. I don't know if something like this is possible. If you know of a good solution to this shared web assets issue, I'd love to hear about it.

Back to AppFuse Light. If I can figure out how to solve shared resources in web modules, I can use this in AppFuse Light to move to a modular SVN structure vs. its current "use Ant to create different combinations" setup. If a modular structure (like appfuse/web/*) is possible for AppFuse Light, I believe it makes sense to move its source into AppFuse's SVN repository. Below is how the directory structure might look after this move.

With this addition and "archetype:create-from-project", we should be able to create all the basic and light archetypes automatically. We'll probably still need a manual archetype-creation process for modular archetypes, but I'm OK with that.

The last thing I'm struggling with is figuring out the best way to create archetypes for something like AppFuse. In the past, we've used dependencies to allow users to inherit dependencies and their versions. This works, but it results in a lot of duplicate XML (in projects and archetypes) for developers. Last night, I tried using a parent project instead of dependencies and it seems to work much better. Not only do you inherit dependencies, but you also inherit plugins, profiles and properties. If you inherit, you can override, which is slick.

If you're an AppFuse user, how would you feel about having an AppFuse module as your project's parent? Would you prefer that, dependencies on AppFuse or full-source with no dependencies on AppFuse? Regardless of parent vs. dependencies, I think running "appfuse:full-source" should allow you to de-couple your project from AppFuse.

Applying Flash to Java: Flex and OpenLaszlo with Dustin Marx

If you're going to choose Flex or OpenLaszlo, chances are you're targeting Flash. The Flash Player allows you to abstract the browser idiosyncrasies and give users a better experience. It hides the browser quirks from both developers and users. It's also a highly ubiquitous web browser runtime environment. It provides a user experience way beyond traditional HTTP request-response. Also, its visual effects and "richness" rival of non-browser desktop applications.

Mark's blog stats show that 95% of readers are using Flash 9 and 1% is Flash 10. All others don't have their version exposed. Most other sources claim that Flash 9 has 98% penetration in mature markets. One of the nicest things about Flash is it frees users from limitations of traditional web applications. Request/response is largely a thing of the past and Ajax-like behavior was built-in from the beginning.

Flash Criticisms: has reduced SEO as well as bookmarking and URL history support.

Flash Player Criticisms: not open source, no significant alternative, no 64-bit player, loading performance and it's only useful for games, movies and annoying advertisements.

The good news is Flash is getting better. There's currently a SWF Searchability initiative with Google and Yahoo!. For bookmarking and URL History, you can use "deep linking" with mx.managers.BrowserManager and mx.managers.HistoryManager. Flash Player issues are also being addressed. There's a Flash Open Screen Project, there's a 64-bit player in Adobe Labs and Flash 9/10 is much better than in the past.

To prove that Flash is a compelling technology, all you have to do is look at Microsoft's Silverlight and Sun's JavaFX. These are direct competitors that are fairly new and prove that companies like what Flash has.

Flex
Flex is not Flash. Flex requires Flash (9+), but Flash does not require Flex. Flex is a language and framework and applications are compiled into .swf files. Flash is the runtime environment that executes .swf files. Flex 3 is FREE. The Flex SDK, compiler and debugger are open source. They have no license costs. BlazeDS is also open source and has no license cost.

Flex MXML was formerly called Macromedia XML. It's an XML-based presentation/layout language that's editable with any text editor or IDE. MXML is to ActionScript 3 as JSP is to Java. MXML provides the layout and ActionScript provides the dynamic business logic.

ActionScript
ActionScript is an ECMAScript implementation that's been proposed as the Edition 4 implementation. It's not your older sibling's JavaScript. It uses class-based object-oriented features and static typing. Thanks to the Flash Player, it works the same across multiple browsers. Most of the things you can do with MXML, you can do with ActionScript. However, MXML typically requires less LOC.

ActionScript allows packages, interfaces, inheritance, objects and methods. It includes extensive XML Support, particularly E4X (ECMAScript for XML). It has a large class library and can talk directly to the Flash Player. Finally, it has many Java-like features and it's syntax looks similar.

At this point, Dustin started doing demos of two popular Flex components: RichText Editor (which creates horrible HTML) and Data Grid. More third-party Flex components seem to appear every day. Examples include flexlib, ASDIA as well as all those listed on FlexBox. Additionally, it's not too difficult to create your own Flex components (no proof provided).

Flex's property binding is one of Dustin's favorite features, but he says he has a difficult time conveying how cool it is. Property binding allows you to tie data in one object to data in another object. Updates in one object affect another. To use it in MXML, you can use curly braces or the tag. In ActionScript, you can use the BindingUtils object. You can also use Flex's metadata annotation "Bindable" to denote bindable objects.

To compile Flex applications, you can use mxmlc from the command line. You can use Ant with the <exec> task or using Flex's Ant Tasks. You can also invoke mxmlc from Java as long as you include mxmlc.jar in your classpath. FlexBuilder is an Eclipse-based IDE that's not included with the free Flex SDK. It's not a free product and can be used as a plugin or a standalone IDE.

Flex and Java
There's two predominant out-of-the-box methods for Flex to communicate with Java EE backends.

• HttpService: traditional HTTP request/response.
• WebService: SOAP-based Web Services.

If the above two methods aren't fast enough, you can use BlaseDS and it's additional options.

• Web Messaging: HTTP publish/subscribe with JMS, ColdFusion and/or other Flash/Ajax client.
• Remoting with AMF: access server-side objects from Flash client-tier as if they were hosted there.

Flash applications can access either a client's machine or a remote site, but not both. You can use a crossdomain.xml file on your server to allow remote Flash clients to connect. This file allows access for both Flex and OpenLaszlo applications.

BlazeDS adds proxy server support for HTTPService and WebService. To use, set the useProxy attribute to "true". Features include authentication and logging. It adds a new RPC mechanisms called RemoteObject. This object allows ActionScript and Java EE transparent integration. It also adds publish/subscribe messaging with a JMS Adapter available. Lastly, it adds Ajax support to your Flex application.

GraniteDS is an open-source (LGPL) alternative to Adobe LiveCycle and is similar to BlazeDS. It has COMET-like functionality and supports Spring, Spring Security, EJB 3, Seam and Guice.

Flex Frameworks: Cairngorm (Adobe Consulting), Pure MVC, Mate and many others.

Flex 4 (Gumbo) will have improvements for designers (easier customization, better tool support), improvements for developers (faster compiler, two-way data binding) and will leverage new features of Flash 10.

OpenLazlo
OpenLaszlo 4 is XML-based and uses an XPath syntax for data access. OpenLaszlo was actually created before Flex and is ECMAScript-based. Unlike Flex that requires Flash 9, OpenLaszlo is architected to deploy on different runtime environments, including: Flash 7/8/9 and DHTML. Dustin believes OpenLaszlo would be a lot more appealing if your source code could be compiled into Silverlight or JavaFX.

OpenLaszlo's syntax looks a lot like Flex, except it does not use namespaces. OpenLaszlo's Constraints are similar to Flex's property binding, except the syntax is a bit different. You use ${} in LZX tags or applyConstraint() and LzDelegate in scripts. OpenLaszlo's event handling is similar to Flex and JavaScript event handling. All attributes have an implicit "on" event that is triggered when an attribute's value is changed. Event handlers can be written CSS-style in LZX nodes or using the <handler></handler> tag. Script code can be embedded in LZX XML in many ways:

• Inside event attributes
• Within <script></script> tags
• Within <method></method> tags
• Within <handler></handler> tags
• In a separate file (<script src="someFile.js" />)

Dustin believes the debugger and view-source tools in OpenLaszlo are much better than the ones available for Flex.

For the rest of the presentation, Dustin covered many of Laszlo's feature, how they relate to Java as well as how to integrate SWF and HTML. SWFObject is Dustin's preferred method for adding Flash to HTML. One of its nifty features is it allows SWF-to-SWF communication.

This talk was an excellent and in-depth overview of Flash, Flex and OpenLaszlo. I especially liked all the details on ActionScript and the different methods for remote communication. Nice job Dustin!

Comprehensive Project Intelligence with Jason van Zyl

In this talk, Jason is going to talk about m2eclipse, Nexus, Hudson and Maven. On his Maven bullet-point, it says "The best is yet to come (and we'll fix a bunch of stuff)!"

m2eclipse
The m2eclipse plugin has improved greatly in the last 4 months - there's now 5 full-time developers working on it. If you use the m2eclipse plugin, you never have to leave the IDE for your Maven-related work. m2eclipse has a Configuration Framework that turns Maven's mumbo-jumbo (Jason's words, not mine) into Eclipse talk. The m2eclipse+configuration framework has integration for WTP, JDT, AJDT and they're working on one for Flex. Below is a screenshot of how m2eclipse helps developers stay away from using command-line Maven.

Now Jason is showing a demo of m2eclipse and creating a new Maven project from existing archetypes. It looks like m2eclipse uses "Nexus Indexer" as its Catalog. Presumably this is a Sonatype-hosted service. The Nexus Indexer contains an of Maven Central and is very fast. It's dynamically updated as new things are deployed to Maven Central.

If you use m2eclipse and open a pom.xml, you'll get a visual view rather than an XML view. This UI has tabs for Overview, Dependencies, Repositories, Build, Plugins, Reporting, Profiles, Team, a Dependency Hierarchy and Dependency Graph. You can easily add new dependencies and it finds things quickly because it's using the Nexus index. In addition to visually adding dependencies, you can modify the raw XML and get things like groupId and version code-completion.

Once you have your dependencies listed in a "Maven Dependencies" container to you can "Materialize Project" to create a project from the binary dependency. You'll get the source as a new project in your workspace as well as having your binary dependency turned into a source dependency.

You can easily create a run configuration that runs certain goals, allows you to activate profiles and uses an embedded version of Maven or an external installation. I asked Jason if the Dependency Hierarchy had a right-click -> exclude feature and he said it doesn't exist yet, but it will in the release after next. For now, the pom editor is just eye candy and doesn't have actions.

For Maven Plugins, m2eclipse has workspace resolution so you can develop a plugin and use it in a project at the same time w/o having to install the plugin over and over.

Sonatype has created a Project Materializer Plugin that allows a team lead to create a project for developers. It allows you to create a welcome page that has links, cheat sheets, News and Updates and Tasks for the developer. It also materializes Eclipse projects in the background. Cheat Sheets are a series of tasks that can be run to show developers how to do things.

Another big feature in m2eclipse is nested project support. It only works in Eclipse 3.4 though.

Nexus
Nexus is a repository manager that allows you to keep the cruft from the outside world out of your system. It's primarily for Repository and Configuration Management. It has fine-grained security for authentication and authorization. One nice feature of its security system is you can prevent certain users from seeing source JARs. It also has virtual repositories (a savior for OSGi lovers). UI is written in Ext JS and acts as a simple REST client for Nexus. It has a full REST API using RESTlet.

A repository manager allows you to protect yourself from the Open Source Ghetto. The OS Maven Ghetto has bad POMs, repositories in POMs, mixed snapshot and release dependencies and screwed up metadata. Not only does it offer protection, but it allows you to aggregate repositories and publish your internal artifacts to it. It also allows you to schedule tasks that clean out snapshots so your repositories don't grow out of control.

Typically people deal with OSGi runtimes manually. OSGi can dynamically update dependencies that you drop into your bundle repository. However, many folks maintain their OSGi runtime and bundle repository locally. Some people are trying to get an OSGi runtime to resolve against a P2 repository. P2 is what Eclipse uses for their repository management. Nexus has the ability to lock down the versions that are available to an OSGi runtime. Furthermore, you can use Nexus to manage the versions that get deployed to all your servers. This makes it a lot easier for QA and Production to manage versions of your artifacts. OSGi is great for modularity and solving classpath issues, but it does have issues with versions and how its ranges work.

You can see Nexus in action at http://repository.sonatype.org. It can be configured entirely through the UI, an XML file or through the REST API. RSS feeds exist for configuration and repository updates.

Nexus is free and open source with a GPL license. The next version (1.2) will contain a Plugin API to allow extensions. All of Sonatype's enhancements for its commercial version will be written as plugins. A matrix of what's available in the open source version vs. commercial version should be published sometime next week.

Hudson
Jason believes that Hudson is the future of continuous integration, on-demand results and release management. They're writing all their extension points in Hudson as Maven plugins and Plexus components (with the work they've done, using Spring components should also be possible). Other enhancements they've made to Hudson:

• Integration of JSecurity
• Implementing a similar REST layer as Nexus and creating a UI using Ext JS
• Automatic installation of external Maven installations
• Drools Workflow Integration

They've also enhanced Hudson so it can easily test/publish Maven projects without using the free-form project template. Hudson works well for doing Eclipse headless builds for Eclipse plugins. If you need to test against multiple databases, multiple OS's, it does support a grid-based system that's easy to setup. Hudson does have web services integration that allows you to kick off builds from within Eclipse. Sonatype uses Hudson to run all their nightly builds of Maven.

Maven - the best is yet to come
The three big things coming in the next version of Maven are:

• Refactored Project Builder: includes a spec for building a pom, domain-specific parsers (attribute-based XML, Groovy and Ruby) and mixins.
• Mercury: a new repository and transport layer. Developed by the Jetty people and is super fast (async client with connection pooling and parallelization). Has atomic downloads and deployments (with Nexus), full PGP support and a WebDAV client built-in.
• Maven Embedder: re-written to actually work.

Overall, a good talk with lots of demos. I'm definitely looking forward to Maven improvements in the future.

Integrating Compass 2.0 into AppFuse

Last week, Chris Barham showed us an example of how to implement external sorting and paging with AppFuse + DisplayTag. This week, he's at it again with a tutorial titled Searching in AppFuse 2.0.2 with Compass 2.0 and Lucene 2.3.2.

From a message he sent to the mailing list:

I've extended the previous DisplayTag external sorting and paging project to implement full search capability across the domain objects by using Compass 2.0 - http://www.compass-project.org.

Although there are a number of tutorials around for Compass and AppFuse, I thought I'd update as Compass has just gone to version 2.0 and has new features, (annotations etc).

Search results in the example are displayed in plain HTML with Compass' own paging feature, and also using DisplayTag with its paging external feature, (both on the same search results page in the example).

Code is in a branch off the original project called branches/search - check it out with:

svn checkout http://pagingappfuse.googlecode.com/svn/branches/search/ appfusecompass

Instructions on how to implement Compass are here:
http://code.google.com/p/pagingappfuse/wiki/CompassSearching

Cheers,
Chris

Again, great work Chris! We really appreciate your contributions.

Issues with AntRun Plugin and Maven

I started seeing the following error today when using Maven and the AntRun Plugin.

[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error executing ant tasks
	
Embedded error: java.lang.IllegalAccessError: tried to access method 
org.apache.tools.ant.launch.Locator.decodeUri(Ljava/lang/String;)Ljava/lang/String; 
from class org.apache.tools.ant.AntClassLoader

Searching the internet provided no results, so I was pretty stumped - especially since this error didn't happen on my MacBook Pro. It happened on AppFuse's Bamboo server (Linux), but not locally. Luckily, I was able to reproduce it on my Windows box and discovered the solution: upgrade to a newer version of Maven. I was using 2.0.6/2.0.7 and upgrading to 2.0.9 fixed the problem.

BTW, when is the Ant project going to release a new version of Ant? The current 1.7.0 version doesn't support spaces in path names, which seems like a pretty big issue to me (especially for Windows users).