The lab utilizes the maven-lab-plugin, which can be used to create step-by-step labs using Maven.

During the lab, i wanted to know which step I was at and I figured that there should be a goal for that. To list the available goals for a maven plugin you can use the goal help:describe like this:

  $ maven help:describe -DgroupId=com.jayway.maven.plugins.lab -DartifactId=maven-lab-plugin

This will give you an output like:

Name: maven-lab-plugin Maven Mojo
Description: Maven plugin used to create labs that provide more code once a
  step has been completed. Labs are a useful way to learn new technologies,
  frameworks and tools.
Group Id: com.jayway.maven.plugins.lab
Artifact Id: maven-lab-plugin
Version: 1.0.0.RELEASE
Goal Prefix: lab

This plugin has 7 goals:

lab:create
  Description: Goal to chunkify

lab:currentStep
  Description: Get the current step no

lab:findMax
  Description: Goal to find the max version

lab:init
  Description: Goal to create and initialize a lab.

lab:next
  Description: Change to next step

lab:reset
  Description: Goal to create and initialize a lab.

lab:setStep
  Description: Change version to versionNo

For more information, run 'mvn help:describe [...] -Ddetail'

The pom is configured to use two different plugins depending on which operating system that is executing it.
On Windows, a Launch4j project plugin will be used. On OS X the osxappbundle plugin is used, which creates an OS X application directory structure and uses the JavaApplicationStub binary for launching the application.

The <profile> tag is used for deciding which plugin to use depending on operating system.

The pom also points out different application icons for the binaries, OS X requires the icon to be in the icns and windows in the ico format.

The wrapped application has a main class in the file com.jayway.wrappedapplication.Launcher

The pom.xml

  4.0.0
  com.jayway.wrappedapplication
  launcher
jar
  1.0-SNAPSHOT
  launcher
  http://maven.apache.org


      windows-deploy
      
        
          Windows
        
      
      


            org.bluestemsoftware.open.maven.plugin
            launch4j-plugin
            1.5.0.0
            
              
                launch4j
verify
                
                  launch4j
                
                
                  false
gui
                  ${project.build.directory}/relauncher-${project.version}.exe
                  ${project.build.directory}/${project.build.finalName}.jar
                  Launcher
                  
                    1.6.0
                  
                  
                    com.jayway.wrappedapplication.Launcher
                    false
anything
                  
                  ${basedir}/build-resources/win/icons/application.ico
                
              
            
          
        
      
    

      
        
          mac
        
      
      


            org.codehaus.mojo
            osxappbundle-maven-plugin
            1.0-alpha-2
            
              com.jayway.wrappedapplication.Launcher
              ${basedir}/build-resources/osx/icons/application.icns
            
            
              
package
                
                  bundle
                
              
            
          
        
      
    
  

And that's it.

What is my interest in all this except that I'm really into cool gaming ideas? Well, Minecraft is written in Java and it is easy to write plugins. Currently there is no official support for mods or plugins, although there probably will be in the future. However, there is lots of unofficial mods and the most promising server side mod seems to be Bukkit which supports plugins. Their wiki includes descriptions how to setup your workspace and how to write a plugin. The best way to learn is probably to take a look at the source of one of the many existing plugins.

There is a sample project available called SamplePlugin which you can use to get started quickly. I have added a simple maven profile that makes it even easier to get started:

git clone https://github.com/jankronquist/SamplePlugin.git
cd SamplePlugin
mvn package -Pstart-server


Happy hacking!

The Current State of Affairs

Most Open Source projects for iOS are distributed as a source code repository with an Xcode project. But here the good news stop for most projects. The Xcode project usually only has one target, a sample project, mixing the reusable code in the same bucket as the sample/incubator code around it.

The usage instructions suggest you drag and drop a directory, or even worse a collection of files, into your own project. This is a very primitive solution, passable in the '80s when all we had was disks and BBS:es, not good enough today. All history and connection back to the source is lost, any value added by source control systems is lost the second you decide to use an open source component this way. Any bug-fix or improvement you make will require a manual merge back to the original project. You also loose all tracking information the moment you copy a file, what version of project X did you use, some special branch?

This Need To Change

This affair also highly discourages re-use. Almost every open source project out there that involves network connectivity also uses Apple's Reachability example code as a base for determining network status. Apple's code is not complete for all use-cases, and not free of bugs, so almost every project has a more or less modified variant of the same code causing compiler errors. Ensuring that using several open source project in one application is bound to end up with conflicts. Leaving it up to you to determine which projects version of Reachability that is the master version, often you end up writing a third version of Reachability for your project. And none of these changes and improvements will ever end up in a re-usable way for the iOS community as a whole.

This is not an impossible problem to solve, in the Java world there is for example Maven that solves this very well. Maven is a huge tool, and re-inventing that wheel for iOS would be a mammoth task. Fortunately that is not needed; Xcode already has the basics that we need in order to create iOS projects that are highly extendable and re-usable.

There is a Solution Today

One Xcode project can have one or more targets, usually the target is your application, sometimes you have one target for iPhone and a separate target for iPad. Targets are not limited to applications, you can also have a Unit-test targets, and more importantly static library targets.

A static library target yield a static library that can be linked into any other target, so be applications or other static libraries. A static library is a cruder version of a Framework, like UIKit and Core Data that Apple provide us. Crude as they are, it is still good enough to use for sharing re-usable Open Source project components.

A Xcode project has the notion of sub-projects. A Xcode sub-project is a reference to another Xcode project. You can set the sub-project's Targets as direct dependencies for your targets, and instruct the sub-projects products to be linked with your products. In essence say "Use what that other Xcode project creates to build my project".

The idea of Xcode's sub-projects has a logical one-on-one mapping to sub-modules in Git. Meaning that exposing re-usable iOS Open Source projects as static libraries on for example github is as easy as can be.

Eating Your Own Dogfood

This is actually what I have done for years, ever since I released HessianKit in 2008. Most of the code you write will be re-usable for the next project, having an easy way group your re-usable components into a growing library will save you a lot of work.

Firstly I never have to start with a blank canvas for any project. But more importantly, when working on many applications, any bug fixes and improvements I make to my shared components immediately trickles out to all other projects as well. If I add animated insert of cells in my column table view for project A, then all other projects is only one git pull away from benefiting from this new feature as well.

Jayway have since a few weeks begun the process of publishing our re-usable components for iOS. So far this has resulted in three projects on github:

• CWFoundation - a collection of new classes and categories to add functionality that is commonly missing from Foundation framework.
• CWUIKit - a collection of classes and categories that do the same for UIKit. CWUIKit requires CWFoundation.
• CWCoreData - A collection of categories for Core Data that makes using Core Data in a multithreaded application a breeze.

These are living projects and will be updated with new functionally over time, and large enough to warrant a blog-post for each on their own. There are also a few Componentized forks of popular iOS open source projects at Jayway's github page.

Tutorial for Using a Sub-Project from a Sub-Module

Working with an environment like this have many benefits, but also requires some knowledge of both Xcode and git. There are a few gotchas to be aware of, limitation of Xcode and the linker, best explained with a short tuturial.

CWUIKit has additions to UIAlertView that allows an alert to be created directly from a NSError instance, just like AppKit do on Mac OS X. Lets walk through how to create a new project that uses this functionality from CWUIKit to display the error message from a faulty URL request.

This tutorial is for Xcode 3.2, but works with minor modifications for Xcode 4. Changes for Xcode 4 are written in block quotes like this.

1. Create new "Window-based Application" from Xcode.

I chose a Window-based app because it contains the least amount of template code, and fits the purpose of an example well.

2. Initialize the project directory as a git repo.

git init

We need to initialize the project directory as a proper git-repo in order to use git's sub-modules.

Skip this step if project is created with git-repo in Xcode 4.

3. Add sub-module

git submodule add git@github.com:jayway/CWUIKit.git Components/CWUIKit

This will create a sub directory named Components, this is where I by convention put all my sub-modules/sub-projects, it is not a hard requirement.

4. Update and initialize all submodules

git submodule update --init --recursive

A git-submodule is by default not initialized, this is to avoid downloading large amount of data for a sub-modules you do not need, such as a test project. This is why we must update and initialize the sub-projects to realize them when starting a new repo or cloning an old one.

5. Add sub-project

Locate CWUIKit.xcodeproj and drag and drop into your project.
Highlight the CWUIKit.xcodeproj item and ensure the "Target Membership" column, that has a bullet as symbol, is checked for the libCWUIKit.a product. This is the static library to link against.
Also add the CWUIKit target as a direct dependency to your applications target so that CWUIKit is automatically build before building your application.

It is not required to setup target membership in Xcode 4, only set Target as Target Dependency in Build Phases tab, and add the Product to be linked in the same tab.

6. Recursive Sub-Projects

Static libraries are by their nature linked into your binary, this means that if static lib A and static lib B both define the same global symbol C you will get a duplicate symbol ‘C’ error when linking you app.
CWUIKit uses functionality from CWFoundation, but because of this limitation of the linker it can not explicitly add this functionality to itself. Doing so would make it impossible to use CWUIKit side-by-side with other projects that also uses CWFoundation, such as CWCoreData.
The work around is that any project that includes CWUIKit must also include CWFoundation. So repeat step 5 with the CWFoundation.xcodeproj from /Components/CWUIKit/Components/CWFoundation.

Xcode 4 has full knowledge of recursive sub-projects, so this step can be skipped. Only add CWFoundation sub-projects product to be linked.

7. Add QuartzCore and OpenGLES frameworks to your target.

Static libraries can not enforce linking of frameworks on it’s own, so building the app in it’s current state would result in missing symbols errors.
Using CWUIKit requires the app to be linked against QuartzCore and OpenGLES frameworks for CoreAnimation and OpenGL additions.

8. Setup header search paths.

Unfortunately sub-projects headers are not automatically added to the search path of your projects. So you must add "Components/**" as a header search path for your project.

Xcode 4 considers header search baths to be an advanced setting, to change the build settings display for Basic to All if you can not find it.

9. Setup linker flags

Add "-all_load" to other linker flags.
The GCC and LLVM linker also has a limitation/bug for static libraries that will strip out any methods for categories on a class that is not defined in the static library. For example any method extending UIAlertView in libCWUIKit.a will be stripped out by this bug.

10. Add #import "CWUIKit.h" to you application delegate. And add this small code to the application:didFinishLaunchingWithOptions: method

NSError* error = nil;
[NSData dataWithContentsOfFile:@"wrong path!"
                       options:nil
                         error:&error];
[[UIAlertView alertViewWithError:error] show];

11. There is no step 11.

But there is a screenshot of the running app.

Conclusions

This method of using Xcode sub-projects and git sub-modules for managing shared components works very well, and scales to be even better the more sub-projects and developers you have. The greatest benefit is without any doubt that bug-fixes and new features by default always trickles back to their source and become re-usable for all.

All the downsides are in the limitations of static libraries themselves, and can unfortunately not be overcome unless Apple introduces proper support for third party frameworks in iOS SDK. The two major gotchas are missing symbols caused by missing frameworks required by dependencies, and duplicate symbols caused by implicit inclusion of dependencies from dependencies. I have found that the best solution is to always have a README with your project where you explicitly name each Framework and Component that is required.

Using Xcode sub-project to manage your builds solves the problem of dependency resolution without the need to write a new system, works on the developer's desktop as well as on a build server. Using git sub-modules to manage your dependencies solves the problem of including all recursive dependencies as well as versioning. Any sub-module can by locked at a particular stable version by commit or tag as required, with full history. But best of all; you as a developer is free to just code away knowing that you can later commit and push your changes back, independently of how or where the code originates.

First, to enable FindBugs reporting in Maven, just add report section to your pom files, something like example below, but of course, you can do your own configuration.

<reporting>
  <plugins>
    <plugin>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>findbugs-maven-plugin</artifactId>
      <version>2.3</version>
      <configuration>
        <excludeFilterFile>exclude.xml</excludeFilterFile>
        <findbugsXmlOutput>true</findbugsXmlOutput>
        <findbugsXmlWithMessages>true</findbugsXmlWithMessages>
        <threshold>Low</threshold>
        <effort>Max</effort>
        <xmlOutput>true</xmlOutput>
      </configuration>
    </plugin>
  </plugins>
</reporting>

Then you can just use command mvn site if you want to generate more comprehensive project information or mvn findbugs:findbugs for only FindBugs reports.

Finally use mvn dashboard:dashboard to generate charts.

Voila. We have got nice graphic reports.
Well, not so nice. We have bugs we need to fix.

Just like EJB2, Maven2 was born out of something so unbearable that anything else was bliss. Jelly anyone!

But just as EJB was fundamentally flawed, so is Maven2. Build systems, even advanced ones like Maven is fundamentally about two things.

1. Check if something that something else depends on has changed
2. If so, do something.

That's it, that is what is important.
The checking may contain various sophisticated methods for detecting if files, subsets of files, all files, web pages, twitter feeds, etc, has changed, but that is really it.
And the doing can be anything, Copy files, commit files, build websites, run tests, generate code, launch missiles, whatever!
But the key to doing this efficiently is a programming language with easy access to system commands and the ability to create simple abstractions, with methods, variables, and objects. The language should also, preferably, be one without a lot of ceremony, like Ruby, Javascript or Python.
There are already build systems like this out there, Buildr, SCons, and Rake come to mind, but they do not have the momentum of Maven, so a merger between Maven and Buildr would be wonderful.

So, Jason, hear my plea, Don't make me eat the elephant again!

When working on www.beertoplist.com I ran into a Maven problem, that is fairly common: Having a project that should be configured differently for different environments. That is for instance you want one configuration for development, one for test and one for production. I wanted a solution that allowed me to make changes to all kind of configuration files, for instance property files, Spring context files and Tomcat context files.

Poor solution

Googling on the problem I found that most people suggested that you should use a set of Maven profiles, one for each environment. So when you want to build the project for test environment you enable the test profile and get all the test configuration. At first glance this might seem like a good solution, but there is a major problem with this solution.

When you have your artifact, how do tell which environment it is configured for? Even worse what if you forget to enable the production profile when releasing or maybe enable the test profile instead. Then you have released a test version of the project and there is no way you can tell except for checking the details in the artifact. Further more you commonly want to deploy the released version to a test environment, but you can not do that out of the box, because the released artifact in the Maven repository is configured for production (if you enabled the right profile). Thus you need to check out the release tag and build a new version with the test profile enabled. Now you end up with two files with the same name and version, that are configured differently. Not a very appealing solution.

My solution

My suggestion is to instead let Maven build one artifact for each configuration and label them accordingly, so when looking at a specific version in the Maven repository you find, one development artifact, one test artifact and one production artifact, each clearly labeled. Then you never run into the problems listed above. So how can we accomplish this?

Maven have the concept of classifiers. This is a suffix that is appended to the name of the artifact to distinguish it from the main artifact. This is used for instance by the source plugin that creates a source jar file for a Maven project, resulting in a file with the name <artifact id>-<version>-sources.jar. The classifier for this file is "sources". The same concept can be used to build a development, a test and a production artifact, which is the solution I choose in www.beertoplist.com.

I decided to put all the environment specific configuration in a special source tree, with the following structure:

+-src/
  +-env/
    +-dev/
    +-test/
    +-prod/

Then I configured the maven-war-plugin to have three different executions (the default plus two extra), one for each environment, producing three different war files: beer-1.0-dev.war, beer-1.0-test.war and beer-1.0-prod.war. Each of these configurations used the standard output files from the project and then copied the content from the corresponding src/env/ directory on to the output files, enabling an override file to be placed in the corresponding src/env/ directory. It also supported copying a full tree structure into the output directory. Thus if you for instance wanted to replace the web.xml in test you simply created the following directory:

src/env/test/WEB-INF/

and placed your test specific web.xml in this directory and if you wanted to override a db.property file placed in the classpath root directory for the test environment you created the following directory:

src/env/test/WEB-INF/classes

and placed your test specific db.property file in this directory.

I kept the src/main directory configured for development environment. The reason for this was to be able to use the maven-jetty-plugin without any extra configuration.

Configuration

Below you find the maven-war-plugin configuration that I used to accomplish this:

<plugin>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <classifier>prod</classifier>
    <webappDirectory>${project.build.directory}/${project.build.finalName}-prod</webappDirectory>
    <webResources>
      <resource>
        <directory>src/env/prod</directory>
      </resource>
    </webResources>
  </configuration>
  <executions>
    <execution>
      <id>package-test</id>
      <phase>package</phase>
      <configuration>
        <classifier>test</classifier>
        <webappDirectory>${project.build.directory}/${project.build.finalName}-test</webappDirectory>
        <webResources>
          <resource>
            <directory>src/env/test</directory>
          </resource>
        </webResources>
      </configuration>
      <goals>
        <goal>war</goal>
      </goals>
    </execution>
    <execution>
      <id>package-dev</id>
      <phase>package</phase>
      <configuration>
        <classifier>dev</classifier>
        <webappDirectory>${project.build.directory}/${project.build.finalName}-dev</webappDirectory>
        <webResources>
          <resource>
            <directory>src/env/dev</directory>
          </resource>
        </webResources>
      </configuration>
      <goals>
        <goal>war</goal>
      </goals>
    </execution>
  </executions>
</plugin>

So what was the problem? Well, I've been using @Configurable and @Autowired to inject stuff in my domain object which I create in code. To get this working when running mvn test you have to pass in spring-agent.jar as javaagent. When you do this, everything worked great! To to this with Maven you have to do the following:

 
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.4</version>
    <configuration>
      <forkMode>once</forkMode>
      <argLine>
        -javaagent:${settings.localRepository}/org/springframework/spring-agent/${spring.version}/spring-agent-${spring.version}.jar
      </argLine>
      <useSystemClassloader>true</useSystemClassloader>
    </configuration>
</plugin>
 

Now, that's all cool, and it worked like a charm... for a while. When I added @Configurable to another class to autowire in a new dependency, I could not get that specific class to get weaved properly. Believe me, I tried everything I could think of, but nothing worked... until I found a hint on a thread with a related problem. By passing in a second javaagent, aspectjweaver.jar, the problem was solved! To do this in Maven you just add the second javaagent after the first, like this:

 
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.4</version>
    <configuration>
      <forkMode>once</forkMode>
      <argLine>
        -javaagent:${settings.localRepository}/org/springframework/spring-agent/${spring.version}/spring-agent-${spring.version}.jar -javaagent:${settings.localRepository}/org/aspectj/aspectjweaver/1.6.1/aspectjweaver-1.6.1.jar
      </argLine>
      <useSystemClassloader>true</useSystemClassloader>
    </configuration>
</plugin>
 

Note: If you add a line-break between the two javaagents, it doesn't work.

What was the problem I had? I have no idea! Why does this solution work? I have no idea! All I know is that I get a green light from my tests, and that I don't need this solution when running live in Tomcat or whatever, since the classloader there has addTransformer(ClassFileTransformer).

Still, if anyone has any idea of why I, after everything worked with only spring-agent.jar, needed to add aspectjweaver I am all ears! Don't get me wrong! I can live with not knowing, but I would get peace of mind from knowing...

However, if your project is set up to use the Maven automatic build versioning as provided by the buildnumber-maven-plugin you will run into problems if it is set to get the build numbers from the Subversion revision number. Since your local checkout is against Git, and not Subversion, the build will fail since the Subversion commands won't work.
One solution for this could be to alter the plugin configuration to get the build number from the date or something similar, but that's not always possible. You might have a build server setup that depends on the build number matching the revision number, and imposing such a change might break other functionality or processes.

Instead you can add an additional profile to the Maven POM which will only be triggered in the absence of a .svn directory (i.e. when not using Subversion). In this profile you can override the default configuration for the build number generator to instead use the date for build numbers. This means that your builds will have different build numbers from the integration builds, but at least it will compile on your git checkout.

The profile will look like this:

<profile>
  <!--
  This profile is here for triggering when another scm than svn is
  used (for example git). Instead of getting the version build number
  from svn we will use the build date and the user name.
  -->
  <id>buildnumber-git</id>
  <activation>
    <file>
      <missing>.svn</missing>
    </file>
  </activation>
  <build>
    <plugins>
      <plugin>
        <groupId>org.codehaus.mojo</groupId>
        <artifactId>buildnumber-maven-plugin</artifactId>
        <executions>
          <execution>
            <phase>generate-resources</phase>
            <goals>
              <goal>create</goal>
            </goals>
          </execution>
        </executions>
        <configuration>
          <doCheck>false</doCheck>
          <doUpdate>false</doUpdate>
          <format>{0,date,yyyy-MM-dd_HH-mm}_{1}</format>
          <items>
            <item>timestamp</item>
            <item>${user.name}</item>
          </items>
        </configuration>
      </plugin>
    </plugins>
  </build>
</profile>

This way Subversion and Git users can live happily together in the same project.

(UPDATED for version 1.3.0. See below.)

Problem

If you have ever tried doing this before with Maven, you have probably used maven-assembly-plugin, which would leave the door open for classpath problems!

It would extract all your dependency jars in one directory together with all your class files and all other classpath resources. The problem is that everything ended up in a big mix, with classpath resources possibly overwriting each other. For example, if two dependencies each had a log4j.properties file in their jar, one log4j.properties would overwrite the other.

No more of that mess!

Solution

Enter maven-onejar-plugin. It lets all your dependency jars stay jars, and your code is in its own jar. All of those jars are put in a bigger jar, which is made executable.

Configuration

It may sound weird, but it's quite elegant! Just put this in your pom.xml's <plugins> tag to make it work:

<plugin>
  <groupId>org.dstovall</groupId>
  <artifactId>onejar-maven-plugin</artifactId>
  <version>1.3.0</version>
  <executions>
    <execution>
      <configuration>
        <mainClass>your.package.YourMainClass</mainClass>
      </configuration>
      <goals>
        <goal>one-jar</goal>
      </goals>
    </execution>
  </executions>
</plugin>

You also need to add this to the pom:

<pluginRepositories>
  <pluginRepository>
    <id>onejar-maven-plugin.googlecode.com</id>
    <url>http://onejar-maven-plugin.googlecode.com/svn/mavenrepo</url>
  </pluginRepository>
</pluginRepositories>

Please note the new Maven repository URL. Me and onejar-maven-plugin founder Drew Stovall just recently moved the project to Google Code to make it more open and easier for others (like me!) to pitch in. Yesterday, I released version 1.2.3 of onejar-maven-plugin to our new Maven repo at Google Code. UPDATE: Just released version 1.3.0 with optional support for including and autoloading native libraries such as .dll files. (detailed usage instructions.)

Make sure you get the <pluginRepository> URL right so that the latest version will be available to you!

Use

Then do this to build everything:

mvn install

That will build both your normal jar, as well as another jar. You will get these:

Standalone one-jar.jar file, along with the original .jar file.

myApp.one-jar.jar is the big executable that includes both myApp.jar, and all dependency jars.

You can run it standalone without any extra files, like this:

java -jar target/myApp.one-jar.jar

If you found this interesting, you might find my post about winstone-maven-plugin enlightning as well. It shows you how to make an executable .war file.

Credits

Thank you Drew Stovall for creating this Maven plugin in the first place, and thank you to the other contributors who have also submitted patches.

Project homepage: http://onejar-maven-plugin.googlecode.com

One area that, in my opinion, could still be improved is the development environment. It may be a heck of a good build system Liferay has come up with, but at the bottom line it takes time to learn it and to just start studying it you easily become a bit uncertain. It consists of homegrown ant scripts. To have a flatter learning curve for newcomers Maven 2 might be suitable.

Anyway, I sat down one evening some time ago and looked into how Maven 2 could be used for creating Jsp Portlets for Liferay. Some hours later the work had resulted in a new archetype for creating Liferay Jsp Portlets.

The structure and content of the standard Liferay Jsp Portlet can be viewed here.

So, what did I do?

1. I followed these instructions to manipulate the Jsp Portlet part of Liferay's plugin SDK into a maven archetype:

http://maven.apache.org/guides/mini/guide-creating-archetypes.html

This involved editing these property and xml files:

liferay-plugin-package.properties
name=${artifactId}
module-group-id=liferay
module-incremental-version=1
tags=
short-description=
change-log=
page-url=http://www.liferay.com
author=Liferay, Inc.
licenses=MIT

portlet.xml
<?xml version="1.0"?>
<portlet-app xmlns="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd" version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd http://java.sun.com/xml/ns/portlet/portlet-app_2_0.xsd">
<portlet>
<portlet-name>jspPortlet</portlet-name>
		<display-name>${artifactId}</display-name>
<portlet-class>${groupId}.JSPPortlet</portlet-class>
		<init-param>
			<name>view-jsp</name>
			<value>/view.jsp</value>
		</init-param>
		<expiration-cache>0</expiration-cache>
		<supports>
			<mime-type>text/html</mime-type>
		</supports>
<portlet-info>
			<title>${artifactId}</title>
			<short-title>${artifactId}</short-title>
			<keywords>${artifactId}</keywords>
		</portlet-info>
		<security-role-ref>
			<role-name>administrator</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>guest</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>power-user</role-name>
		</security-role-ref>
		<security-role-ref>
			<role-name>user</role-name>
		</security-role-ref>
	</portlet>
</portlet-app>
 

to insert ${artifactId} and ${groupId} for the portlet name and package structure. These files are part of the file list finally being wrapped up within the archetype and used to generate the resulting portlet from Maven 2.

2. I ran 'mvn install' on that particular archetype to have it installed in my local repository.

3. I used the archetype to create a new Liferay Jsp Portlet artifact:

mvn archetype:create -DarchetypeGroupId=com.liferay.maven.archetypes.portlet.jsp
  -DarchetypeArtifactId=liferay-jsp-portlet
  -DarchetypeVersion=1.0-SNAPSHOT
  -DgroupId=[my.package]
  -DartifactId=[MyFirstLiferayJspPortlet]

4. I stepped into the artifact and ran 'mvn install' on it which generated my MyFirstLiferayJspPortlet-1.0-SNAPSHOT.war.

5. I then uploaded the war file to my portal instance via the Liferay admin GUI Plugin Installer.

6. Et voila. It worked, showing up in the portal.

And of course, worth mentioning, to have a development environment up and running in eclipse in seconds this is all you have to do:

1. mvn eclipse:add-maven-repo -Declipse.workspace=[full-path-to-workspace]

2. mvn eclipse:eclipse

To have the archetype play with the existing build situation of Liferay it would probably need to be generated from some ant target and be based on the portlet template in subversion located at "plugins/tools/portlet_tmpl/" to have it follow updates of Liferay.

Here you can download the final result, as a zipped archetype.

If a generated archetype like this was to be uploaded to a public maven repository, working from above point #3 and down is what would be necessary for a developer to have a project and all the necessary property and xml files (correctly edited with package structures and all) in place for a Liferay Jsp Portlet development environment. It could at least become a complement to the Plugins SDK. And yes, it could for sure still be enhanced. For example, there is no JSPPortletTest class generated for the JSPPortlet class.

If your project is configured with a Maven pom.xml and the module has <packaging>war</packaging>, you can just add this little piece of XML inside the pom's <plugins> tag:

<plugin>
    <groupId>net.sf.alchim</groupId>
    <artifactId>winstone-maven-plugin</artifactId>
    <executions>
        <execution>
            <goals>
                <goal>embed</goal>
            </goals>
            <phase>package</phase>
        </execution>
    </executions>
</plugin>

Then, when you run...

mvn install

...winstone-maven-plugin will automatically create a *-standalone.jar file for you, which contains your web application.

Standalone .jar file, along with the .war file.

You can run that .jar file as a standalone application, which runs your included web application on port 8080 by default:

java -jar target/*-standalone.jar

No web server installation necessary! No external files required! (You don't even need the .war file anymore.)

The resulting .jar file is actually the servlet container Winstone, with your .war file deployed inside it.

There are more configuration options on winstone-maven-plugin's usage page.

I want to disable some default features of Winstone for security reasons, because they are not needed: ajp13 listener on a separate port, servlet invoker and directory listings. This is the complete plugin configuration I usually use myself:

<plugin>
    <groupId>net.sf.alchim</groupId>
    <artifactId>winstone-maven-plugin</artifactId>
    <version>1.2</version>
    <configuration>
        <cmdLineOptions>
            <property>
                <name>httpPort</name>
                <value>8080</value>
            </property>
            <property>
                <name>ajp13Port</name>
                <value>-1</value>
            </property>
            <property>
                <name>controlPort</name>
                <value>-1</value>
            </property>
            <property>
                <name>directoryListings</name>
                <value>false</value>
            </property>
            <property>
                <name>useInvoker</name>
                <value>false</value>
            </property>
        </cmdLineOptions>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>embed</goal>
            </goals>
            <phase>package</phase>
        </execution>
    </executions>
</plugin>

You can temporarily override these configuration parameters if you like, using command-line options when executing the standalone .jar file. Find them with --help when you run the .jar.