The Lazy Dev

In this two parts article, I am explaining how to configure Maven to manage a multi branded project and development environment. In the first part the Maven side of the problem is analysed.
In this second part, I will address how Wicket handles the branded configuration and how to make the development environment "brand-friendly".

Wicket side

We have to inject the brand into the application. Wicket has an Application that we normally extend in a MyWicketApplication class. In this class we should put a field called "brand" with regular Java accessors (actually, only the setter is a must). We can inject the actual brand value using web.xml (like in [2]) or, if we use Spring for configuration, we go with:

 <bean id="wicketApplication" class="com.myapp.MyWicketapplication">
   ...
   <property name="brand" value="${brand}"></property>
 </bean>

By the way, this Spring file normally is under src/main/resources that has filtering set to true in maven configuration:

<resource>
    <filtering>true</filtering>
    <directory>src/main/resources</directory>
</resource>

From now on we just use wicket built-in support for skinning, or "style", as called in Wicket. In our MyWicketApplication we should override newSession method:

public class MyWicketApplication extends WebApplication {
 ...
@Override
   public Session newSession(Request request, Response response) {
      Session session = super.newSession(request, response);
      session.setStyle(brand);
      return session;
   }
 ...
}

That's all. Now, automagically, Wicket will first look for resources in the file called:

MyWicketApplication_stage.properties

before trying the standard MyWicketApplication.properties. Please note that as of wicket Javadoc [3], style and i18n are both supported at the same time. For a more detailed analysis on how this work in Wicket, take a look at reference [2].

A brand-friendly development environment

In the end, with some configuration we have all the work done and we do not have to deal with this problem in the code. Nice results.
But we also want our development sessions to be comfortable with this set up. For me development environment means Eclipse, automated testing in eclipse and maven and an embedded Jetty where to run the webapp.
Fortunately, the folder layout is great for both the testing environment and Eclipse: a simple "mvn eclipse:eclipse -P companyA" will make the branded folder to be used as a source folder in eclipse, and this is great.

We need a little more work for the "mvn jetty:run". In this setup, jetty embedded will run without take care about the war and will take static content directly from configured static sources folder, that means, by default in maven, only "src/main/webapp". We need to add our new static content branded folder. So let's give maven jetty plugin this special configuration.

         <plugin>
            <groupId>org.mortbay.jetty</groupId>
            <artifactId>maven-jetty-plugin</artifactId>
            <configuration>
 ...
               <webAppConfig>
                   <baseResource implementation="org.mortbay.resource.ResourceCollection">
                     <resourcesAsCSV>src/main/webapp,src/main/brands/${brand}</resourcesAsCSV>
                  </baseResource>
               </webAppConfig>
 ....
            </configuration>
         </plugin>

Now is time for the final, glamorous touch. I want a single command to make all the development environment switch from a brand to another. The I define a shell alias called brand, like this:

alias brand='mvn clean eclipse:eclipse test-compile -o -P '

Now I can call:

brand companyA

Switching between brands becomes quick and simple.

I love it when a plan comes together

[2] http://javathoughts.capesugarbird.com/2007/08/branding-wicket-application-take-2.html
[3] http://wicket.apache.org/docs/1.4/org/apache/wicket/Session.html