To create a simple project:

mvn org.apache.maven.plugins:maven-archetype-plugin:2.0-alpha-4:create -DarchetypeGroupId=org.scala-tools.archetypes -DarchetypeArtifactId=scala-archetype-simple -DarchetypeVersion=1.2 -DremoteRepositories=http://scala-tools.org/repo-releases -DgroupId=com.mycompany.scala -DartifactId=scalaTest

To run the sample:


mvn compile exec:java -Dexec.mainClass=com.mycompany.scala.App


Quem começa com o Google Web Toolkit (GWT), logo percebe que a distribuição não funciona em todos os sistemas operacionais. É preciso fazer o download do gwt-linux, gwt-mac ou gwt-windows. Isso porque a distribuição inclui bibliotecas nativas SWT, Mozilla, e scripts para executar a aplicação no modo “hosted”, que diferem entre os vários sistemas operacionais. Além disso, a distribuição não inclui scripts para criar um WAR “deployável” com a aplicação GWT.

Uma opção ao uso da distribuição do GWT, é o uso de um archetype maven que faz todo o trabalho de gestão das diferenças entres os vários sitemas operacionais, além de oferecer a possibilidade de criar um WAR com uma linha de comando. Para  criar o projeto, basta chamar o archetype:


mvn archetype:create -DarchetypeGroupId=com.totsp.gwt \
-DarchetypeArtifactId=maven-googlewebtoolkit2-archetype \
-DarchetypeVersion=1.0.3 \
-DremoteRepositories=http://gwt-maven.googlecode.com/svn/trunk/mavenrepo \
-DgroupId=br.com.dominio \
-DartifactId=app-gwt


Para executar o projeto, use o goal gwt:

mvn gwt:gwt

Antes de gerar o WAR, é preciso descomentar a linha “<!– <webXml>target/web.xml</webXml>–>” no plugin war e a linha ” <!–mergewebxml–>” do plugin maven-googlewebtoolkit2-plugin, tudo isso no pom.xml gerado. Isso porque o GWT no modo “hosted” utiliza um xml (chamado Application.gwt.xml) para declara configurações client-side E server-side. Caso você esteja utilizando RPC, o plugin maven fará um merge do Application.gwt.xml para um web.xml, migrando todas as declarações de servlet.

E finalmente para gerar o WAR, basta:

mvn package

The maven jetty plugin is a handy plug-in that allows to run a maven based project that has a web-app inside simply by doing a “mvn jetty:run”, without the hassle of creating a WAR and deploy it to somewhere else.

It happens that the jetty web server, by default, does not handle URLs that contains double slashes “//”, that is, calling http://host/mycontext/media//img/a.gif is not the same as calling http://host/mycontext/media/img/a.gif, and brings a 404 error (as described in http://jira.codehaus.org/browse/JETTY-386)

To enable url compactation in the jetty through maven plug-in, and thus enabling the same behaviour as tomcat:

<plugins>
           ...
           <plugin>
                      <groupId>org.mortbay.jetty</groupId>
                      <artifactId>maven-jetty-plugin</artifactId>
                      <configuration>
                                <scanIntervalSeconds>10</scanIntervalSeconds>
                                <connectors>
                                       <connector implementation="org.mortbay.jetty.nio.SelectChannelConnector">
                                               <port>8080</port>
                                               <maxIdleTime>60000</maxIdleTime>
                                       </connector>
                                </connectors>
                                <webAppConfig>
                                       <contextPath>/mycontext</contextPath>
                                       <compactPath>true</compactPath>
                                </webAppConfig>
                    </configuration>
           </plugin>
           ...
</plugins>

Who uses maven as I do for a long time, knows that sometimes things does not go as expected. So it’s necessary to look at the ultimate documentation: the source code! In this post I’ll show how to debug a maven plugin using Eclipse’s remote debugger. I’ve chosen for this example the maven-clean-plugin.

Ok, let’s start. First create a simple sample project:

    mvn archetype:create -DgroupId=com.wordpress -DartifactId=maven-debug

In the folder maven-debug, edit the pom.xml and add the dependency of the plugin. This will serve as an “anchor” to bring all the sources needed to debug.

<dependency>
       <groupId>org.apache.maven.plugins</groupId>
       <artifactId>maven-clean-plugin</artifactId>
       <version>2.1.1</version>
       <scope>provided</scope>
</dependency>

Note the scope “provided”, meaning that the dependency will be given to the project by someone and it should not make to the final package. It shouldn’t matter, anyway, since this is a dependency that will be removed later, it’s just for debug purposes.

It’s important to know what version of the plugin your project is using. When in doubt, run “mvn -X clean” and note lines like:

  [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::3 for project:
           null:maven-clean-plugin:maven-plugin:2.1.1 from the repository.

Now generate the project in eclipse:

   mvn -Declipse.downloadSources=true eclipse:eclipse

Open eclipse, go to File -> Import -> Existing Projects into Workspace and select the root directory of the project. After that go to menu
“Run –> Open debug dialog” and under “Remote java application” create a new profile to debug our project:

Using the eclipse search facilities, search for a class which name ends with “Mojo” (Maven Old Java Object) and place a breakpoint in the “execute” method. In the case of the clean plugin, this class is called CleanMojo

To debug, first enable debug on maven in the command line (linux shown here)

MAVEN_OPTS="-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8000";
export MAVEN_OPTS

and then do a “mvn clean”; the process will halt. Start the debugger in eclipse, it will hit the breakpoint.

Congratulations! Now you can know exactly what’s going on!