Apache Maven is more than just build automation. When positioned at the very heart of your development strategy, Apache Maven can become a force multiplier not just for individual developers but for Agile teams and managers.

In this article by Srirangan, author of Apache Maven 3 Cookbook, we will cover:

• Integrating Scala development with Maven
• Integrating Groovy development with Maven
• Integrating Flex development with Maven

Apache Maven 3 Cookbook

Over 50 recipes towards optimal Java Software Engineering with Maven 3

(For more resources on this subject, see here.)

Java has been the dominant enterprise programming platform for over a decade and a half. In many ways, it has shaped the way the industry does business, especially with the advent of the Internet and followed by cloud computing. It is very evolved and mature, and has good infrastructure support.

For all its successes, however, it has some serious problems competing with modern dynamic programming languages in the context of ease of programming, especially while getting started in the initial stages of a project.

An advantage that Java traditionally enjoyed over the likes of Python, Ruby, and so on is that a lot of enterprises were committed to Java Virtual Machine (JVM) as their platform due to its inherent advantages. This always worked in favor of the Java programming language.

However, all this has changed with modern languages such as Scala, Groovy, and so on supporting JVM bytecode, which made them compatible with existing enterprise infrastructure and assets. Furthermore, RIA (Rich Internet Applications) technology, such as Flex, never faced the JVM challenge in the first place due to the widespread adoption of the Flash Player.

Apache Maven's flexible plugin-based architecture allows the tools to evolve with time and lends its benefits to developers and development teams that are keen to leverage this new breed of modern programming languages.

Integrating Scala development with Maven

Scala stands for "Scalable Language". It is defined as a multi-paradigm programming language and has integrated support for object-oriented programming and functional programming.

It runs on the JVM and on Android. Furthermore, it can read existing Java libraries which give it a huge advantage in cases where there is a lot of existing code infrastructure in Java.

The Scala bytecode is in many ways, identical to the Java bytecode. In many cases, Scala generates more optimal byte-code than Java.

Twitter, Foursquare, and a whole bunch of exciting software startups have adopted Scala. Scala helped Twitter get over its scalability issues when the micro blogging pioneer first hit the mainstream and needed to scale-up as it served millions of new users each day

This is, of course, not to say that scalable applications can't be built in pure Java. However, the Scala programming language features itself (such as pattern matching, concurrency, and Actors) and frameworks built on top of Scala (for example, Akka, GridGain, and so on.) allow application scalability with ease.

Below is an example of a popular sorting algorithm implemented in Scala:

def qsort: List[Int] => List[Int] = {
  case Nil => Nil
  case pivot :: tail =>
  val (smaller, rest) = tail.partition(_ < pivot)
  qsort(smaller) ::: pivot :: qsort(rest)
}

The creator of Scala, Martin Odersky, has given a number of popular talks and presentations examining Scala's comparability. When Scala code is up against comparable code in other programming languages including Java, C#, Ruby, and so on, the conciseness of Scala really stands out.

The Scala implementation of quicksort in the preceding code demonstrates this very conciseness of Scala code.

While the Scala community recommends SBT (Simple Built Tool) for pure Scala projects, often you'll be implementing modules in Scala while other modules of the project would have been built with Java. This is one of the strongest cases for using Maven in a multi-modular project with Java and Scala-based modules. It is probably the reason why SBT is more or less compatible with Maven's conventions and even provides a feature for "Mavenizing" an existing SBT project.

Getting ready

You'll need Apache Maven installed. The Maven version preferably should be Maven 3 but Maven 2.0.7 or higher is supported. JDK 1.5 or higher is recommended. Do note, installation of Scala is not required. Apache Maven will take care of the Scala dependency.

How to do it...

Generate the Scala project archetype:

$ mvn archetype:generate

This will show a list of available archetypes in which you need to select the archetype for a simple Scala project, which is scala-archetype-simple.

Maven interactive mode will also ask you for archetype version, groupId, artifactId, and other Maven project coordinates. This is the same step we've encountered in previous recipes. You can choose reasonable values for groupId, artifactId, and package. For me, the groupId was net.srirangan.packt.maven, artifactId was scalaexample, version was the default value, and package was the same as groupId. On completion, your terminal will look similar to the following lines:

[INFO] ------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------
[INFO] Total time: 1:38.142s
[INFO] Final Memory: 10M/114M
[INFO] ------------------------------------------------------------

The completion of this operation has created a project folder with the same name as the project artifact ID. The project directory tree structure would look similar to this:

Folder PATH listing for volume OS
Volume serial number is 7C69-DF5D
C:.
└───src
├───main
│   └───scala
│       └───net
│           └───srirangan
│               └───packt
│                   └───maven
│                       └───App.scala
└───test
    └───scala
        └───samples
            └───junit.scala
            └───scalatest.scala
            └───specs.scala

Also generated is a simple Hello World! Scala application–App.scala:

package net.srirangan.packt.maven
object App {
  def foo(x : Array[String]) = x.foldLeft("")((a,b) => a + b)
  def main(args : Array[String]) {
    println( "Hello World!" )
    println("concat arguments = " + foo(args))
  }
}

The pom.xml file is configured in a way that integrated the build lifecycle with the Maven Scala plugin:

<build>
    <plugins>
        <plugin>
          <groupId>org.scala-tools</groupId>
          <artifactId>maven-scala-plugin</artifactId>
            <executions>
              <execution>
                <goals>
                  <goal>compile</goal>
                  <goal>testCompile</goal>
                </goals>
              </execution>
            </executions>
            ...
        </plugin>
    </plugins>
</build>

To compile the project, run:

$ mvn compile

To run the tests, use the default project lifecycle command:

$ mvn test

How it works…

If you inspect the Scala project pom.xml file that was generated, you would see dependencies defined for Scala: library, testing, specs, and scalatest.

<dependencies>
  <dependency>
    <groupId>org.scala-lang</groupId>
    <artifactId>scala-library</artifactId>
    <version>2.9.0-1
    </version>
  </dependency>
  <dependency>
    <groupId>org.scala-tools.testing</groupId>
    <artifactId>specs_2.9.0-1</artifactId>
    <version>1.6.5</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>org.scalatest</groupId>
    <artifactId>scalatest</artifactId>
    <version>1.2</version>
    <scope>test</scope>
  </dependency>
</dependencies>

The first dependency listed here is the Scala programming language itself, that is, org. scala-lang.scala-library. The other two dependencies are for running Scala tests. There may also be a fourth dependency which is not listed in the preceding code for I. It is unrelated to Scala.

Looking at the build settings and plugin configuration hereafter, we see that the source and test directories are being set to src/main/scala and src/test/scala respectively. The plugin execution is being bound to the compile and testCompile build phases.

<build>
    <sourceDirectory>src/main/scala</sourceDirectory>
    <testSourceDirectory>src/test/scala</testSourceDirectory>
    <plugins>
      <plugin>
        <groupId>org.scala-tools</groupId>
        <artifactId>maven-scala-plugin</artifactId>
        <version>2.15.0</version>
        <executions>
        <execution>
          <goals>
            <goal>compile</goal>
            <goal>testCompile</goal>
          </goals>
          <configuration>
            <args>
              <arg>-make:transitive</arg>
              <arg>-dependencyfile</arg>
              <arg>${project.build.directory}/.scala_dependencies</
arg>
            </args>
          </configuration>
        </execution>
      </executions>
    </plugin>
    ...
  </plugins>
</build>

There's more…

In addition to what was described up to now, the Maven Scala plugin has more features which meet the needs of most developers and development situations. The following table lists all goals made available by the Maven Scala plugin, their respective Apache Maven console commands, and brief explanations:

Apache Maven 3 Cookbook

Over 50 recipes towards optimal Java Software Engineering with Maven 3

Published: August 2011
eBook Price: $23.99
Book Price: $39.99
See more

close

Select your format and quantity:

Book 01234567891011121314151617181920

eBook 01234567891011121314151617181920

(For more resources on this subject, see here.)

Integrating Groovy development with Maven

Groovy, which is an object-oriented programming language for the Java Virtual Machine (JVM), provides dynamic programming features similar to Python, Ruby, Smalltalk, and so on. It is often used as a scripting language and interacts freely with existing Java code and libraries.

Groovy was created by James Strachan and Bob McWhirter and is currently being lead by Guillaume Laforge. It is released under the Apache License v2.0.

Groovy is defined as an agile and dynamic programming/scripting language built for the Java Virtual Machine. While it is inspired by Python, Ruby, and Smalltalk; for a Java developer it promises an "almost-zero" learning curve.

In the past few years, Groovy has become popular for scripting and DSLs (Domain Specific Languages) in addition to its use in application development. In an application development environment, Groovy enhances developer productivity by reducing scaffolding code while providing built-in capability for unit and mock testing.

Groovy is based on the JVM and thus interoperates with existing Java-based infrastructure, libraries, and frameworks.

You can find more information on the official Groovy website http://groovy.codehaus.org/

Getting ready

Apache Maven needs to be installed and set up along with JDK. Apache Maven 3+ and JDK 1.6+ are recommended. The Groovy setup is not required as the dependency is taken care of by Maven.

How to do it...

Generate the Groovy project archetype:

$ mvn archetype:generate

This will show a list of available archetypes in which you need to select the archetype for a basic Groovy project, which is gmaven-archetype-basic. Maven interactive mode will also ask you for the archetype version, groupId, artifactId, and other Maven project coordinates.

Alternatively, you can try executing:

$ mvn archetype:generate -DarchetypeGroupId=org.codehaus.groovy.
maven.archetypes -DarchetypeArtifactId=gmaven-archetype-basic
-DarchetypeVersion=<VERSION>

On completion, your terminal will look similar:

[INFO] -----------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] -----------------------------------------------------------
[INFO] Total time: 1:38.142s
[INFO] Final Memory: 10M/114M
[INFO] -----------------------------------------------------------

The completion of this operation has created a project folder with the same name as the project artifact ID. The project directory tree structure would look similar to this:

C:.
└───pom.xml
└───src
    ├───main
    │   └───groovy
    │       └───net
    │           └───srirangan
    │               └───packt
    │                   └───maven
    │                       └───Example.groovy
    │                       └───Helper.java
    └───test
        └───groovy
            └───net
                └───srirangan
                    └───packt
                        └───maven
                            └───ExampleTest.groovy
                            └───HelperTest.groovy

What has been generated is a simple "Hello world!" Groovy application–Example.groovy:

package net.srirangan.packt.maven
/**
 * Example Groovy class.
 */
class Example
{
 def show() {
   println 'Hello World'
 }
}

The pom.xml file is configured in a way that integrated the build lifecycle with the Maven Groovy plugin:

<build>
  <plugins>
    <plugin>
      <groupId>org.codehaus.groovy.maven</groupId>
      <artifactId>gmaven-plugin</artifactId>
      <version>1.0</version>
        <executions>
          <execution>
            <goals>
              <goal>generateStubs</goal>
              <goal>compile</goal>
              <goal>generateTestStubs</goal>
              <goal>testCompile</goal>
            </goals>
                    </execution>
        </executions>
    </plugin>
  </plugins>
</build>

To compile the project, run:

$ mvn compile

To run the tests, use the default project lifecycle command:

$ mvn test

How it works...

If you inspect the POM file (pom.xml) of the Groovy project that was generated, you will find declared dependencies, as shown in the following code:

<dependency>
  <groupId>org.codehaus.groovy.maven.runtime</groupId>
  <artifactId>gmaven-runtime-1.6</artifactId>
  <version>1.0</version>
</dependency>
<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>3.8.1</version>
  <scope>test</scope>
</dependency>

The first dependency listed here is the GMaven runtime, that is, gmaven-runtime-1.6. The other dependency listed in the preceding code is junit which is unrelated to Groovy. It is used for running unit tests.

With the help of the GMaven plugin, these dependencies are integrated with the Maven build lifecycle and the build workflow for the developer is achieved through Apache Maven.

One of the advantages of Apache Maven is on display here, as despite the various differences in underlying technologies, libraries, and toolkits, the Maven build lifecycle, the interface for the developer, and external tools remains consistent.

There's more...

Groovy Shell provides the developer with a very convenient command-line shell to execute Groovy commands. The GMaven plugin provides for command-line access to the Groovy shell with the following command:

$ mvn groovy:shell

The Groovy Shell can be accessed. If you prefer a GUI access to the shell, run the following command:

$ mvn groovy:console

Integrating Flex development with Maven

Adobe Flex is one of the pioneers and leaders in the Rich Internet Applications (RIA) space and with the advent of Adobe AIR, it has proved itself as a viable option for desktop and mobile applications as well.

Here's how Adobe describes Flex on http://www.adobe.com/products/flex/:

"Build engaging, cross-platform rich Internet applications
Flex is a highly productive, free, open source framework for building expressive web applications that deploy consistently on all major browsers, desktops, and operating systems by leveraging the Adobe® Flash® Player and Adobe AIR® runtimes."

Flex is a rich framework that lets you build rich applications for deployment on the Internet as well as desktops and devices. Flex application code consists of MXML (.mxml) and ActionScript (.as) files, classes, and packages. It compiles to produce a SWF (.swf) artifact that can be rendered in the Flash Player and Adobe AIR runtime.

While Adobe ships a good IDE, that is, Adobe Flash Builder and it brings with it an Eclipse project structure, it is generally advisable to "Mavenize" your Adobe Flex project especially if it's a large enterprise project with multiple developers involved.

As an Apache Maven project, the Flex module be integrated with a unified build.

Getting ready

You need Apache Maven installed. Preferred versions are Apache Maven 3 along with JDK 1.6 or higher. The Adobe Flex SDK is an Apache Maven project dependency and will be automatically included when required.

How to do it...

Generate a Maven Flex project using the FlexMojos application archetype:

$ mvn archetype:generate

This will show a list of available archetypes in which you need to select the flexmojos- archetypes-application archetype (which is number 353 for me). Maven interactive mode will also ask you for archetype version, groupId, artifactId, and other Maven project coordinates.

On completion, your terminal will look similar:

[INFO] ------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------
[INFO] Total time: 2:55.017s
[INFO] Final Memory: 10M/114M
[INFO] ------------------------------------------------------------

The completion of this operation has created a project folder with the same name as the project artifact ID. The project directory tree structure will look similar to this:

C:.
└───src
    ├───main
│   ├───flex
│   │   └───Main.mxml
│   └───resources
└───test
    └───flex
        └───net
            └───srirangan
                └───packt
                    └───maven
                        └───TestApp.as

As seen above, a Flex application, Main.mxml, was generated. The file template was created by Marvin Herman Froeder and is distributed with the Apache License through the flexmojos archetype. The contents for the file are:

...
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
layout="absolute">
  <mx:Text text="Hello World!"/>
</mx:Application>

Another file generated is TestApp.as in the src/test folder, which contains a simple test case:

package net.srirangan.packt.maven
{
  import flexunit.framework.TestCase;
  import Main;
  public class TestApp extends TestCase
  {
    public function testNothing():void
    {
      //TODO un implemented
      trace("Hello test");
    }
  }
}

Let's inspect the project dependencies defined in the POM file (pom.xml in the project root folder):

<dependencies>
  <dependency>
    <groupId>com.adobe.flex.framework</groupId>
    <artifactId>flex-framework</artifactId>
    <version>4.0.0.13875</version>
    <type>pom</type>
  </dependency>
  <dependency>
    <groupId>com.adobe.flexunit</groupId>
    <artifactId>flexunit</artifactId>
    <version>0.85</version>
    <type>swc</type>
    <scope>test</scope>
  </dependency>
</dependencies>

It's as simple and beautiful as it can get. Just the two dependencies—one for the Flex framework itself followed by the flexunit dependency for unit testing.

Let's now compile our Apache Maven–Flex project:

$ mvn compile

And let's run the unit tests:

$ mvn test

You can combine these two steps by running:

$ mvn install

How it works...

In the How to do it... section above, we created a new Adobe Flex project using an Apache Maven archetype. We have also seen how to execute Maven build lifecycle phases for the project (compile, test, install, and so on).

While inspecting the project POM file (pom.xml), we see that the flexmojos plugin is integrated with the default build cycle:

<build>
  <sourceDirectory>src/main/flex</sourceDirectory>
  <testSourceDirectory>src/test/flex</testSourceDirectory>
  <plugins>
    <plugin>
      <groupId>org.sonatype.flexmojos</groupId>
      <artifactId>flexmojos-maven-plugin</artifactId>
      <version>4.0-pre-alpha-1</version>
      <extensions>true</extensions>
    </plugin>
  </plugins>
</build>

The POM also reveals that the packaging of the project is swf as Flex projects generate output in the Flash Player format, namely, SWF:

<groupId>net.srirangan.packt.maven</groupId>
<artifactId>TestFlexApp</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>swf</packaging>

There's more...

In addition to the compilation and test features we witnessed above, the flexmojos plugin provides many more goals that cater to most of our needs as Flex developers. The table below lists the flexmojos goal, its corresponding Maven command, and an explanation of its function:

Summary

This article discussed the popular upcoming technologies and frameworks, namely Scala, Groovy, and Flex and got you started on these with Apache Maven.

Further resources related to this subject:

• Apache Felix Gogo[article]
• Configuring Apache and Nginx[article]
• Migration from Apache to Lighttpd[article]

Apache Maven 3 Cookbook

Over 50 recipes towards optimal Java Software Engineering with Maven 3

Published: August 2011
eBook Price: $23.99
Book Price: $39.99
See more

close

Select your format and quantity:

Book 01234567891011121314151617181920

eBook 01234567891011121314151617181920

About the Author :

Books From Packt