Raible Designs

RE: Jetty Ant Plugin

It looks like Jetty has a new Plugin for Ant. If you've used the Jetty Maven Plugin, you know this is a slick way to quickly deploy your application. For those of you wondering about Tomcat, there's a similar Tomcat Maven Plugin that supports tomcat:run and tomcat:run-war. However, it's still in Mojo's sandbox.

I'm pumped to see this Jetty task for Ant because I've been thinking a lot about creating an exploded, full-source archetype for AppFuse 2.0. Of course, it's probably possible to start Jetty and monitor your project for changes w/o this task - but it does seem to make things a fair amount easier. If we do a full-source archetype, it makes sense to support Ant as well - especially since we can probably re-use the build.xml from AppFuse Light.

This brings up a related questions I asked on the AppFuse mailing list yesterday:

A couple of questions for folks using (or planning to use) 2.x:

1. As far as archetypes go, are you using basic or modular?

2. If there was a 3rd type of archetype that included the full source (like AppFuse 1.x), would you use it over the existing basic or modular archetypes? If yes, I'm assuming upgrading is not that big of an issue for you?

If you've tried AppFuse 2.x and would like to answer these questions, please add a comment.

There's another questions about Selenium vs. Canoo WebTest in that post, but that's reserved for another entry where I'll talk about Selenium options in Maven 2.

Zero Configuration in Struts 2

Struts 2 has a nifty zero configuration feature. However, it's only useful for registering actions, not for automatically registering results. In other words, you still have to use an @Result annotation to tell your action what page to dispatch to. To use default view names instead of requiring @Result, you can use the Codebehind Plugin. Also, did you know Struts 2 will autowire your Spring dependencies? It's pretty slick.

What does this all mean? It means you can write your Struts 2 application without writing any XML. Of course, you can still use XML to tweak behavior, but with these plugins enabled, you won't have to.

IMO, these plugins should be combined into a single zero configuration feature.

Here's how you can enable Struts 2's Zero Configuration feature in AppFuse 2.0:

1. Add a packageNames parameter to the "struts" filter in your web.xml:
   

   <filter>
       <filter-name>struts</filter-name>
       <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class>
       <init-param>
           <param-name>actionPackages</param-name>
           <param-value>com.company.newapp.webapp.action</param-value>
       </init-param>
   </filter>
   

2. Add the Codebehind Plugin as a dependency in your pom.xml:

   <dependency>
       <groupId>org.apache.struts</groupId>
       <artifactId>struts2-codebehind-plugin</artifactId>
       <version>2.0.6</version>
   </dependency>
   

3. Add a struts.codebehind.pathPrefix constant in struts.xml for your default pages directory:

   <constant name="struts.codebehind.pathPrefix" value="/WEB-INF/pages/"/>
   

That's it - now you can code away without configuring anything!

How does this compare to other web frameworks in AppFuse? Tapestry has a similar feature, but Spring MVC and JSF don't. Spring MVC still requires you create a bean definition for Controllers and JSF requires you write a chunk of XML for each managed bean. Of course, if you know how to do something similar with Spring MVC or JSF, please let me know.

Artifactory - a new Maven 2 Repository Manager for Enterprises

From the Maven 2 user list:

We would like to announce the immediate availability of Artifactory, a Maven 2 enterprise proxy.

Artifactory offers advanced proxying, caching and security facilities to answer the needs of a robust, reproducible and independent build environment using Maven 2. It uses a JSR-170 Java Content Repository (JCR) for storage, which makes it extremely easy to manage searchable metadata, and provide extended features such as security, transacted operations, auditing, locking, etc.

Artifactory is distributed under APLv2 at http://artifactory.sourceforge.net. It is currently available as a downloadable archive, that can be run out of the box (with default settings). An install script to run it as a Linux service is also provided. A (limited) guest live demo is available at http://www.jfrog.org/artifactory (username/password is guest/guest).

You are welcome to give it a go!

Cheers,

Yoav Landman,
The Artifactory Team

So how does this compare to Archiva, Proximity and Maven Proxy? One user writes (formatted for better reading):

It's interesting to see that Artifactory's UI is powered by Wicket and Dojo. The demo seems kind of sluggish, but I don't believe this application is meant to handle more than 10 users at a time. For more information on Artifactory's features, see its introduction page.

It's great to see a (seemingly) good tool come out for internal repository management.

I spent a couple days last week analyzing the best open source continuous integration server for Maven 2 projects. Hudson turned out to be the clear winner with the best UI and easiest setup. It also actually worked, which is a lot more than I can say for Continuum. While I did get Continuum to work, it required turning on anonymous SVN (no, putting the username/password in the URL did not work). CruiseControl worked as well, but required config.xml knowledge, which sometimes scares admins. Pulse and Bamboo continue to be the best commercial Maven 2 testers, while TeamCity failed my 10-minute test (twice!). One of the features I was looking for was Trac integration and that only exists for CruiseControl and Continuum.

It's amazing to see projects like Continuum and Archiva. If they're any reflection of the Maven team's ability to develop software, that's frightening. My advice: discontinue both of these projects as they're a waste of anyone's time to even research them.

Update October 2009: Fast forward a couple years and I take back what I said about the Maven's team ability to develop good software. Nexus is a kick-ass Repository Manager.

Upgrading to MyFaces 1.1.5 and Spring 2.x + Resin 3.x + Cargo

This week, I encountered a few issues with some open source software that I hadn't seen before. Furthermore, it was difficult to find the problems' solutions via Google, so I figured I'd blog about them and make life less painful for the next person.

Upgrading MyFaces to 1.1.5
The first issue I experienced was when I tried to upgrade from MyFaces 1.1.4 to 1.1.5. After upgrading, my Canoo WebTests failed on some pages because the page kept redirecting to itself instead of submitting a form and properly processing the result. The solution was found with a simple e-mail to the project's mailing list. If you have a view template that auto-submits to a backing bean, you need to change "_link_hidden_" to "_idcl". Apparently, this change was made to be more similar to the JSF RI. Of course, this hack wouldn't be necessary if JSF would simply allow you to call a method from a URL without going to a view page first.

Spring 2.0's RequestContextListener has issues on Resin and WebSphere
Spring 2.0.2 has a bug where its RequestContextListener throws a NPE on WebSphere 6.0 and Resin 3.x. This is fixed in Spring 2.0.3.

Making Resin 3.x XSD-aware when using Cargo
By default, Resin 3.x doesn't ship with an XSD-aware parser turned on. This means that if you're using Spring 2.0 XSDs, you will need to set some configuration options on Resin. I don't know why Resin doesn't ship with these on by default, but it doesn't. This presents a problem if you're using Cargo to download and install Resin. The good news is you can configure Cargo to set system properties and turn Resin's XSD parser on. Adding the following to the <container> element in the Cargo plugin's configuration to solve the problem.

<!-- Make Resin aware of Spring 2.0 XSDs -->
<systemProperties>
    <javax.xml.parsers.DocumentBuilderFactory>
        org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
    </javax.xml.parsers.DocumentBuilderFactory>
    <javax.xml.parsers.SAXParserFactory>
        org.apache.xerces.jaxp.SAXParserFactoryImpl
     </javax.xml.parsers.SAXParserFactory>
</systemProperties>

Resin and Cargo
Finally, Cargo 0.2 throws a NoClassDefFoundError when shutting down Resin 3.0.23 and doesn't work at all with Resin 3.1.0. What does this mean? It means Cargo works great with Tomcat and JBoss, but not so good with Resin 3.x, Jetty 6.x or Geronimo 1.1.

It's too bad, Cargo really is a great project idea. Maybe the container developers should get involved to help it support all the latest versions?

Java is more complicated than .NET ... unless you use AppFuse

From Java to .NET, Back To Java Again, My Little Impression of The Two:

Having said all these, integration of various java projects together really do take a lot of Java people's time, it's no joke, but it's not desperate. For example, the open source project "AppFuse" does a fantastic job integrating various frameworks for us, I strongly encourage everyone to give it a shot and see how much time it saves you.

So which platform do I like? My impression is Java offers a lot flexibility and choices, but at the same time introduced the "Paradox of Choices", having so many things and integrate them together is no easy task, it simply overwhelm the human brains. .NET on the other hand is in a controlled environment, less choices, but easy to develop.

In other words: Java development is way more complicated than .NET ... unless you use AppFuse.

Database Profiles in AppFuse 2.0

Last night, I added several database profiles to AppFuse 2.0 and its archetypes. What does this mean? It means AppFuse should work out-of-the-box with several databases, including:

• H2
• HSQLDB
• MySQL
• PostgreSQL
• SQL Server

For example, here's how to test a new AppFuse project works with H2:

mvn archetype:create -DarchetypeGroupId=org.appfuse -DarchetypeArtifactId=appfuse-basic-struts -DremoteRepositories=http://static.appfuse.org/repository -DarchetypeVersion=1.0-m4-SNAPSHOT -DgroupId=com.mycompany -DartifactId=myproject

Yeah, I wish there was a way to shorten this command (or prompt for choices) too.

After doing this, you can cd into the "myproject" directory and run mvn integration-test -Ph2. AppFuse 2.0 projects are configured for MySQL by default, so if you want to permanently activate one of these profiles, you can add the following between the <id> and <properties> section of the profile.

    <activation>
        <activeByDefault>true</activeByDefault>
    </activation>

In addition to the profiles listed above, I tried to get Oracle Express and embedded Derby working. No dice on either one. I took a brief look at DB2 Express as well, but with a 400 MB download and 3 JARs required for its JDBC Driver - it seemed like a lot more trouble than it was worth.

Maven 2's build profiles are a powerful feature that we hope to make easy to use. For example, to test your new project with H2 and JBoss, you can simply run mvn integration-test -Ph2,jboss. Thanks to the power of Cargo, this will download JBoss 4.0.5, install it, and run all the Canoo WebTests within it. Of course, this will take a while the first time - especially since JBoss is a 77MB download. Fortunately, we allow you to change one small setting in your pom.xml and use an existing install instead.

Maven 2 is a kick-ass build/deploy/test tool once you figure it out. With AppFuse 2.0, we're doing all the "figuring out" for you.

NOTE: I would add more server profiles, but Cargo's Maven Plugin (version 0.2) has issues with Geronimo 1.1, Jetty 6.x and Resin 3.x. Strangely enough, Jetty's Maven Plugin version 6.0.0 works great, but 6.1.0 throws stack traces.

Update: Support for Oracle and Derby (in networked mode) has been added. We'll consider adding support for DB2 if IBM can figure out how to package their JDBC Driver into a single JAR.

Slick looking Confluence sites

You have to admit, both Wicket and Cayenne have nice looking websites. Did you know they're both backed by Confluence? Wicket has a Writing documentation page that explains how it works. Basically, they use the autoexport plugin to export their content to static files. If you configure this plugin to be invoked from a cron job, it's a great way to create a constantly updating dynamic-but-static site.

I believe there's a couple reasons Apache uses this setup: 1) it allows projects to customize the look and feel of their site w/o customizing how Confluence looks and 2) it reduces load on its servers since most content is served up statically. I've thought about using a similar setup for AppFuse's documentation, but I've run into a couple issues:

• The autoexport plugin is pretty flaky. The latest release (0.13) doesn't work with Confluence 2.2.9. Strangely enough, the previous version (0.12) works fine. It looks like the author had a good run with this plugin when he created it (almost a year ago), but hasn't updated it since.
• The dynamic tree menu doesn't get included in the export. If I could somehow include this tree (and the current theme) when exporting, it'd be very cool.
• The new code macro works much better than the {code} macro, but it has exporting issues both with PDF and the autoexport plugin. I tried using the code macro, but it doesn't show any syntax highlighting when using an Adaptavist Builder theme.

Apache's setup for Confluence appears to be quite good. I wonder if we should use it for AppFuse? We don't have the bandwidth/load issues that they do - and we've managed to make the site look decent using Adaptavist Builder. I like having a single source of constantly changing documentation, rather than two sites, where one is static. I think this causes confusion for users if the documentation changes a lot. That being said, I would like to export the content for bundling and versioning with each release. I wonder if Atlassian is planning on fixing the new code macro exporting issue anytime soon?

AppFuse 2.0 M3 Released

The AppFuse team is pleased to announce the release of AppFuse 2.0 M3! This release marks a milestone in our documentation efforts. We've completed all of the web framework tutorials and ensured that all the archetypes work properly. Turkish language support was added and native2ascii was integrated so all i18n bundles should work properly.

The major things missing from this release are code generation (AppGen) and web services (XFire) support. We hope to add both of these before the final release.

AppFuse 2.0 is available as a Maven archetype. For information on creating a new project using this release, please see the QuickStart Guide.

The 2.0 series of AppFuse has a minumum requirement of the following specification versions:

• Java Servlet 2.4 and JavaServer Pages (JSP) 2.0
• Java 2 Standard Platform Edition (J2SE) 5.0

For more information, please see the 2.0 M3 Release Notes.

We appreciate the time and effort everyone has put toward contributing code and documentation, posting to the mailing lists, and logging issues. We also greatly appreciate the help from our sponsors, particularly Atlassian, Cenqua, Contegix, JetBrains, Java.net and KGBInternet. Without them, working on this project wouldn't be nearly as much fun.

Maven 2 hates Commons Logging

It's true that most people hate commons-logging, but Maven 2 hates it even more. There are many open source projects that use this library, so you're likely to depend on it when you never intended to. Of course, this is Maven 2's transitive dependencies fault - but currently there's no option to turn transitivity off. I tried changing to SLF4J, but that causes some Maven plugins to fail.

Since the Maven team refuses to fix this (even though it's an *obvious* exception to their rule about not changing anything), I've fixed it myself. The AppFuse repo has a fixed version of commons-logging's pom.xml. To get the fixed version of commons-logging, delete it from your local repo, then add AppFuse's repository to your pom.xml:

    <repositories>
        <repository>
            <id>appfuse</id>
            <url>http://static.appfuse.org/repository</url>
        </repository>
    </repositories>

Since the burden of this issue clearly rests upon the shoulders of the commons-logging developers - can we please get a new release with a fixed pom? Pretty please?

Update: I tried to get slf4j to work again today. While I succeeded, I found a critical bug. The bug is that log messages don't print out the method name, just debug(), info() or whatever from your classes. It's possible to fix this by using slf4j instead of clogging. However, that won't help you get method names printed when cranking up the logging for 3rd party libraries like Spring and Hibernate. Since this won't be fixed, it seems better to stick with commons-logging. I doubt I'd have any luck getting all the libraries that AppFuse uses to move away from commons-logging.

Simplified UI Tags in Struts 2

Struts 2.0.3 contains a much needed simplification of its UI tag libraries. Before 2.0.3, you had to define a property three times (in the value, label and name attributes):

<s:textfield label="%{getText('user.firstName')}" name="user.firstName" 
    value="%{user.firstName}" cssClass="text medium"/>

In 2.0.3+, you can use the "key" attribute to replace all these attributes. For example:

<s:textfield key="user.firstName" cssClass="text medium"/>

One of the things I really like about WebWork/Struts 2 is the previous examples have the ability to write out the entire form row, rather than just an input field. Even better, the markup rendered is customizable via FreeMarker templates.

The bad news is Struts 2.0.3 never got released because the struts-annotations project hasn't had a release yet (good ol' Mavenism). The good news is Struts 2.0.4 is rumored to be out by the end of the month. In the meantime, if you're using Maven 2, you can use AppFuse's repository to get the goods. Here's the repo settings you're need:

<repositories>
    <repository>
        <id>appfuse</id>
        <name>AppFuse Repository</name>
        <url>http://static.appfuse.org/repository</url>
    </repository>
    <repository>
        <id>struts-203-staging</id>
        <name>Apache Struts 2.0.3 Staging Repository</name>
        <url>http://people.apache.org/builds/struts/2.0.3/m2-staging-repository</url>
    </repository>
</repositories>

Yeah, I could just advise you to use AppFuse 2.0 - but we're having a hard enough time supporting our existing users.