Utku Utkan's Tech Blog: 2008

Friday, December 19, 2008

How to Exclude Web Resources in Maven 2

According to the maven-war-plugin documentation, Web resources can be excluded according to the following syntax.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <configuration>
        <webResources>
            <resource>
                <directory>src/main/webapp</directory>
                <excludes>
                    <exclude>css/**</exclude>
                    <exclude>images/**</exclude>
                    <exclude>js/**</exclude>
                </excludes>
            </resource>
        </webResources>
    </configuration>
</plugin>

However, this syntax does not seem to be working. After investigating the source code, I realized that in fact this plugin expects an excludes element containing a comma separated list of patterns. Following is a sample that I have used successfully in one of my projects to exclude static content. You should also notice that, patterns are relative to the src/main/webapp folder.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
    <configuration>
        <excludes>css/**,images/**,js/**</excludes>
    </configuration>
</plugin>

Wednesday, August 6, 2008

To be, or not to be auto-wired, that is the question.

If properly used, Spring's auto-wire feature might be really handy and it can reduce the volume of your configuration files. It is possible to auto-wire beans by their types or names; but my favorite is auto-wiring by name. You can find more information about this feature here. But now, I want to emphasize one big disadvantage of auto-wiring.

Consider that we are developing an application that will store users and their authorities (roles). In this application, there will be two Data Access Objects (DAO) to deal with User and Authority entity classes, and a service class that depends on these two DAO classes.

In this scenario without using the auto-wire feature our configuration file will look like:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:p="http://www.springframework.org/schema/p"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

    <!-- DAO Beans -->

    <bean id="userDao"
        class="org.hoydaa.autowire.dao.impl.UserDaoImpl" />

    <bean id="authorityDao"
        class="org.hoydaa.autowire.dao.impl.AuthorityDaoImpl" />

    <!-- Service Beans -->

    <bean id="userService"
        class="org.hoydaa.autowire.service.impl.UserServiceImpl"
        p:userDao-ref="userDao"
        p:authorityDao-ref="authorityDao" />

</beans>

However, when the auto-wire feature is enabled, configuration file will be as simple as:

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:p="http://www.springframework.org/schema/p"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd"
    default-autowire="byName">

    <!-- DAO Beans -->

    <bean id="userDao"
        class="org.hoydaa.autowire.dao.impl.UserDaoImpl" />

    <bean id="authorityDao"
        class="org.hoydaa.autowire.dao.impl.AuthorityDaoImpl" />

    <!-- Service Beans -->

    <bean id="userService"
        class="org.hoydaa.autowire.service.impl.UserServiceImpl" />

</beans>

Although the XML file is way more simple, the dependency information between the beans is lost. In my opinion, it is very good to have such a place listing all the dependency between the beans clearly. By looking at this simple configuration file I cannot say that the User Service depends on User DAO and Authority DAO. When the auto-wire feature is enabled, the only way to learn this information is to inspect all the Java classes.

Saturday, May 3, 2008

JSTL 1.2 with Tomcat 6

The new Tomcat 6 does not come with JSTL 1.2 pre-installed. If you are going to use JSTL in a Web application then you should manually add this support by putting the required library (jstl-1.2.jar) to the lib folder of Tomcat. You can download the latest version of JSTL from here.

If you are managing your project with Maven, you should also apply these extra steps.

1. Add this repository element either into pom.xml/<project>/<repositories>, or into conf/settings.xml/<profiles>/<profile>/<repositories>.

<repository>
    <id>java.net</id>
    <url>http://download.java.net/maven/1</url>
    <layout>legacy</layout>
</repository>

2. Add this dependency element into pom.xml/<project>/<dependencies>.

<dependency>
    <groupId>jstl</groupId>
    <artifactId>jstl</artifactId>
    <version>1.2</version>
    <scope>provided</scope>
</dependency>

Tuesday, April 22, 2008

Handling Animated GIFs with GWT

GWT provides an interesting mechanism to deal with images called image bundle. "An image bundle is a composition of many images into a single image, along with an interface for accessing the individual images from within the composite." However this creative approach has a problem. When you use an animated GIF in a page, you just see a normal image with no animation. If you really need an animated GIF, then you should use the com.google.gwt.user.client.ui.Image class. Below is an example snippet demonstrating the use of com.google.gwt.user.client.ui.Image class. For this example, assume that there is a an animated GIF named ajax-loader.gif inside the public folder of your application.

package org.hoydaa.gwtimage.client;

import com.google.gwt.core.client.EntryPoint;
import com.google.gwt.user.client.ui.Image;
import com.google.gwt.user.client.ui.RootPanel;

public class GWTImage implements EntryPoint {

    public void onModuleLoad() {
        Image image = new Image("ajax-loader.gif");
        RootPanel.get().add(image);
    }

}

Friday, February 29, 2008

Common English Words Ignored by Lucene

While indexing Lucene ignores some common English words, because they rarely add any value to a search. These words are considered as noise; and ignoring them actually improves the search quality. If you have ever wondered what these words are, here is the complete list.

a, an, and, are, as, at, be, but, by, for, if, in, into, is, it, no, not, of, on, or, such, that, the, their, then, there, these, they, this, to, was, will, with

Thursday, February 28, 2008

Multiple Module Projects with Eclipse

Maven is a great tool to manage your projects and Eclipse is a great IDE to develop applications. However, there are some points Maven and Eclipse repel with each other. One of them is the project layout. Eclipse insists on flat project layout. On the other hand, Maven manages multiple module projects with hierarchical layout by default. For example, consider a demo project that consists of two sub-modules demo-core and demo-ui. According to Maven defaults, project layout will be as follows:

demo
|-- pom.xml
|-- demo-core
|   `-- pom.xml
`-- demo-ui
    `-- pom.xml

This layout leads to some problems when you want to import these projects (demo, demo-core, and demo-ui) into Eclipse. One way to solve this issue is to configure Maven for using flat project layout. Directory structure for this kind of layout will be as follows:

demo
`-- pom.xml
demo-core
`-- pom.xml
demo-ui
`-- pom.xml

This is what Eclipse really likes. Off course, this does not happen by itself. First, we should modify the modules element of the parent POM as follows:

<modules>
    <module>../demo-core</module>
    <module>../demo-ui</module>
</modules>

After this small change, you can develop your multiple module projects in an Eclipse environment with no problem.

Utku Utkan's Tech Blog

Pages