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.2.3</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. 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.

 
<bean id="traditionalPersonDao"
      class="org.springframework.ldap.samples.article.dao.TraditionalPersonDaoImpl">
<property name="url" value="ldap://localhost:3901" />
<property name="base" value="dc=jayway,dc=se" />
<property name="userDn" value="uid=admin,ou=system" />
<property name="password" value="secret" />
</bean>
 

In order to simplify deployment and maintenance, it's quite common to extract properties related to server names, ports, and user credentials from the Spring configuration file into a separate property file, like in this ldap.properties:

url=ldap://localhost:3901
userDn=uid=admin,ou=system
password=secret

In the configuration file, the previously hard-coded values are replaced with "property placeholders", ie variables enclosed with ${}:

 
<bean id="traditionalPersonDao"
      class="org.springframework.ldap.samples.article.dao.TraditionalPersonDaoImpl">
<property name="url" value="${url}" />
<property name="base" value="dc=jayway,dc=se" />
<property name="userDn" value="${userDn}" />
<property name="password" value="${password}" />
</bean>
 

In order to perform the property value substitution in a transparent way, a PropertyPlaceholderConfigurer is configured:

 
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location" value="classpath:/config/ldap.properties" />
</bean>
 

Spring will pick up that one has been configured and run it before any beans are instantiated. It will read the property file and replace the placeholders with the actual values. Quite handy and very simple.

But what if your organization dislikes having sensitive information like passwords lying around in property files, in clear text? Let's say that your boss demands that all such passwords must be encrypted. Wouldn't it be great if the password then somehow could be automatically decrypted before being used? This can quite easily be achieved using the Jasypt library.

It's a two-step process. First we need to encrypt the password. Then we configure a different PropertyPlaceholderConfigurer that is capable of decrypting the property after it has been read.

Encrypting the password

The available encryption algorithms are currently limited to Password Based Encryptors (PBE). There are scripts for encrypting and decrypting in the Jasypt distribution. This is the procedure for encrypting a text (assuming the Jasypt library has been unpacked in JASYPT_HOME):

% cd $JASYPT_HOME/bin
% chmod +x *.sh
% ./encrypt.sh input="This is my message to be encrypted" password=MYPAS_WORD verbose=false
p3ZVFhK+aqQCyvSk9uWk7p/eisyPbXp3zt3sqnEZsn1Z5plr4CHNC/HHqlgRQ7I3

Let's verify that it can actually be decrypted:

% ./decrypt.sh input="p3ZVFhK+aqQCyvSk9uWk7p/eisyPbXp3zt3sqnEZsn1Z5plr4CHNC/HHqlgRQ7I3"
    password=MYPAS_WORD verbose=false
This is my message to be encrypted

Good. Note that the encryption is "salted", so you'll never get the same result twice. You'll always be able to decrypt it, though. Want to see? OK, one more time then:

% ./encrypt.sh input="This is my message to be encrypted" password=MYPAS_WORD verbose=false
Zi68CfrcLndtKg0npE9OScr+7qNJmWrcO8XI7ZGyucjFiqT9h1FnAIxyezbqNjQq

% ./decrypt.sh input="Zi68CfrcLndtKg0npE9OScr+7qNJmWrcO8XI7ZGyucjFiqT9h1FnAIxyezbqNjQq"
    password=MYPAS_WORD verbose=false
This is my message to be encrypted

Now, let's encrypt our password:

% ./encrypt.sh input="secret" password=MYPAS_WORD verbose=false
6mbJVZ6jozGYF1pjjqDQOQ==

We'll replace the password value in the properties file with the string above, surrounded by ENC():

url=ldap://localhost:3901
userDn=uid=admin,ou=system
password=ENC(6mbJVZ6jozGYF1pjjqDQOQ==)

Configure A Decrypting PropertyPlaceholderConfigurer

We'll simply replace our existing PropertyPlaceholderConfigurer with the Jasypt EncryptablePropertyPlaceholderConfigurer:

 
<bean class="org.jasypt.spring.properties.EncryptablePropertyPlaceholderConfigurer">
   <constructor-arg ref="configurationEncryptor" />
<property name="location" value="classpath:/config/ldap.properties" />
</bean>
 

It delegates the actual decryption to a StringEncryptor implementation:

 
<bean id="configurationEncryptor" class="org.jasypt.encryption.pbe.StandardPBEStringEncryptor">
<property name="config" ref="environmentVariablesConfiguration" />
</bean>
 

The encryptor in turn needs a configuration that provides information such as the algorithm to use and the encryption password. It delegates that responsibility to a PBEConfig implementation that expects the password to be available in an environment variable or a system property:

 
<bean id="environmentVariablesConfiguration"
      class="org.jasypt.encryption.pbe.config.EnvironmentStringPBEConfig">
<property name="algorithm" value="PBEWithMD5AndDES" />
<property name="passwordEnvName" value="APP_ENCRYPTION_PASSWORD" />
</bean>
 

Providing the encryption password as a system property is actually a good thing. A system property can be cleared just when the application has started, thereby minimizing considerably the time that the password is exposed.

Running The Application

It won't work with a Maven property:

% mvn test -DAPP_ENCRYPTION_PASSWORD=MYPAS_WORD
...
Tests run: 8, Failures: 0, Errors: 8, Skipped: 0
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] There are test failures.

Please refer to target/surefire-reports for the individual test results

We check the Surefire reports and find the cause of the error:

org.jasypt.exceptions.EncryptionInitializationException:
  Password not set for Password Based Encryptor

It does however work with an environment variable:

% export APP_ENCRYPTION_PASSWORD=MYPAS_WORD
% mvn test
...
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
...
% unset APP_ENCRYPTION_PASSWORD

Issues With Java5

If we're on Java5 (or lower), we'll need ICU4J. Otherwise, we'll run into this:

org.jasypt.exceptions.EncryptionInitializationException:
  java.lang.NoClassDefFoundError: com/ibm/icu/text/Normalizer

There are two places where we'll need ICU4J: the command line tools and our Maven project.

ICU4J With The Command Line Tools

Reviewing the Jasypt scripts, we find that it's possible to customize the classpath:

export JASYPT_CLASSPATH=~/Downloads/icu4j-4_0.jar

ICU4J With Maven

Add this profile to the Maven pom.xml to get ICU4J in the classpath:

 
<profiles>
<profile>
      <id>jdk15</id>
      <activation>
         <jdk>1.5</jdk>
      </activation>
      <dependencies>
         <dependency>
            <groupId>com.ibm.icu</groupId>
            <artifactId>icu4j</artifactId>
            <version>3.8</version>
         </dependency>
      </dependencies>
   </profile>
</profiles>
 

Currently, the 4.0 version is not available in the central Maven repo, but 3.8 seems to work just fine.

Summary

Using Jasypt, it's actually quite easy to use encrypted values in your property files. In a Spring-based application, it's simply a question of replacing the existing PropertyPlaceholderConfigurer with the Jasypt encrypting equivalent, plus two more beans providing encryption and configuration. Choose how to provide the encryption password, and you're set to go.

If running on Java5 or lower, you'll also need to add ICU4J to your classpath, for the encryption scripts as well as your build and deployment environment.

References

• http://jasypt.org
• http://www.springframework.org
• http://icu-project.org/

When I first started looking at Neo4j I was blown away by how precise the graph database structure matched my mental model of information. You have blobs of informations (nodes with preferences) that relates to other blobs of information. Perfect!

When I started playing around with the API I couldn’t do what I wanted, namely extend NodeImpl and make the objects I want to persist Nodes. Now, Neo4j has a very nice API which is hard to abuse (if you don’t place your classes in the same namespace as they use), and understandably they don’t want you to extend NodeImpl. The design guide gives this example of use:

 
public class CustomerImpl implements Customer{
 
        private final Node underlyingNode;
 
        private static final String KEY_FIRST_NAME = "firstName";
 
        CustomerImpl( Node underlyingNode ){
                this.underlyingNode = underlyingNode;
        }
 
        public void setFirstName( String firstName ){
                underlyingNode.setProperty( KEY_FIRST_NAME, firstName );
        }
 
        public String getFirstName(){
                return ( String ) underlyingNode.getProperty( KEY_FIRST_NAME );
        }
 
        // ...
}
 

That’s great, but it doesn’t match what I see in my head... In order to make things match I made a subtle change.

 
public class NodeDelegate implements Node {
 
        private Node delegate;
 
        protected NodeDelegate(Node node) {
                delegate = node;
        }
 
        // Delegate all methods of the Node interface to the
        // Node received in the constructor...
}
 
public class CustomerNode extends NodeDelegate implements Customer {
 
        private static final String KEY_FIRST_NAME = "firstName";
 
        CustomerNode(Node node) {
                super(node);
        }
 
        public void setFirstName( String firstName ){
                setProperty( KEY_FIRST_NAME, firstName );
        }
 
        public String getFirstName(){
                return ( String ) getProperty( KEY_FIRST_NAME );
        }
 
        // ...
 
}
 

By doing this I can work with my domain objects as Nodes. I don’t know if it is "correct" but with this small change I can say that "A Customer IS a Node" and this is what I see in my head. Good? Bad? You be the judge, but it fits me

On the Mac it was easy to get running (if you have MacPorts):

% sudo port install squid
% sudo squid -z (initialize stuff if you never ran Squid before)
% sudo squid -N -d 1 (no daemon, debug level 1)

Then it was running on the console, and you could test it like this:

% squidclient http://google.com
...
X-Cache: MISS from myhostname
Via: 1.0 myhostname:3128 (squid/2.7.STABLE2)

And again, this time fetching from the cache:

% squidclient http://google.com
...
X-Cache: HIT from myhostname
Via: 1.0 myhostname:3128 (squid/2.7.STABLE2)

You configure your browser by simply setting proxy server to localhost:3128, if you are running your Squid locally, that is.

Maven is probably best configured in ~/.m2/settings.xml:

<settings xmlns="http://maven.apache.org/POM/4.0.0"
    xmlns:xsi="http://www.w3.org/2001/xmlSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
    http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <proxies>
    <proxy>
      <active>true</active>
      <protocol>http</protocol>
      <host>localhost</host>
      <port>3128</port>
    </proxy>
  </proxies>
</settings>

Not only the provided Frameworks are polished even in beta, so are the tools. Mac OS X 10.5 Leopard, and Xcode 3.1 is required! If you can live with that works perfectly, with zero setup; double click install package and you are done. Several project templates provided as starting points. Only drawback I find is that the Simulator is not an emulator of the actual hardware, eg. it is running 32-bit x86 not ARM, which makes an Java JIT-compiler undebuggable on the Simulator. Good news is that there is transparent on-device debugging, bad news again; it requires the 2.0 beta software on the phone.

My second reaction is that it is complete. The SDK, as well as the underlying system. It truly is the same system as on desktop Macs running on the device. The same kernel, the same Frameworks. Just a bit more restrictive memory, and screen size.

The documentation is impressive, ranging from conceptual books and a wide range of subjects such as as Human Interface Guidelines, Memory Management, introduction to Objective-C for beginners, writing games using Open GL | ES, security, and much more.

It is obvious by looking at the documentation provided that special care has been taken to cater for the needs of developers without previous experience of Cocoa, or Mac OS X development. Two thirds of the documentation is very basic for anyone with more then a few months experience with Cocoa. And the last third is in depths iPhone OS specific. Most of the documentation is also shared between iPhone OS and desktop Mac OS X, my gut feeling is that Apple want to use iPhone as a lure for developers to embrace Cocoa on Mac OS X as well.

Apart from documentation there is also over 4 hours of video tutorials, ranging from basic overview to optimizing OpenGL | ES games. As well as over 40 example projects, including complete applications. Bot the "show a feature" type that Android have in bounty, and "show a solution" that gives a better feel for how an application should be organized.

And organizing an application is important. Just as with Cocoa for Mac OS X, Cocoa Touch for iPhone OS gives the developer allot for free, provided you follow a few guidelines, and best practices. These are however few, and clear, so anyone can get the hang of it in a matter of hours. Cocoa's inherent talkative API:s with descriptive class, method and constant names, encourages developers to both use and follow "good style". A method named applicationDidLaunch is very hard to misinterpret (It is however misspelled as ApplicationDidLaunch in the iPhone OS Development Introduction ).

And my last reaction; it is beta! Interface Integration is not yet included. That means that you will have to create your UI in code, not using the drag-n-drop as shown on the Keynote last thursday. I miss it dearly, but try to tell myself it is a good thing to first learn how it works under the hood . That and a short list of known bugs, is really the only things I can see standing in the way of a 1.0 release.

I have as a tutorial for myself rewritten the URLyBird assignment for my Java Developer certification with the iPhone OS SDK. Minus the remote server it is up and running beautifully in less than 8 hours of coding.

I used the Jungle Disk software to provide the mapping from the S3 web service interface to a network drive. You give Jungle Disk your S3 account information, and it provides a network disk which you can use as the backup device. I first tried my existing backup software (Synchronize! Pro X) and it happily began creating directories and copying files. I then tried the backup feature built into Jungle Disk, and it works fine too. It's not fast compared to a local FireWire disk. It's limited to your upload bandwidth, which often is substantially smaller than the download bandwidth.

Anyway, it has been tugging along today storing 5 GB of by digital photos. It feels pretty good to know that my photos are now stored encrypted and with 99.99% availability somewhere far far away, costing me only 75 cents per month after the initial $2 for the transfer.

Setup

Cable modem from ISP, network cable to a firewall, the private end of the firewall via network cable on to a switch. Pretty basic, I guess. No wireless base stations or anything. Just an iMac connected via network cable to the switch.

Problem

Share the iMac's network cable connection through its Airport wireless capability. The client is a MacBook Pro. Basically, I just want to get Internet access on my laptop via the iMac. Sounds simple, but hey, it took me half a day and plenty of research to figure out.

Useful pieces of information gathered during this adventure

1. Turning on Internet Connection Sharing (ICS) will start a DHCP server.
2. Turning on ICS will create a full Airport network (not a computer-to-computer network).
3. Turning on ICS will create a new network configuration for 10.0.2.1, which I understand is the same address as the Airport base stations use.

Solution

1. On the iMac, set the Airport network to "Use DHCP with manual address" and set the IP to 10.0.2.1. Set the DNS servers to the ones recommended by your ISP. Apply.
2. On the iMac, go to Sharing|Internet and choose AirPort Options. Enable WEP encryption (I chose 40-bit with a 5 character password). The default network name is your computer name. I added a postfix to the network name ("-ics") so I can distinguish it from the computer-to-computer network. Apply.
3. Now start sharing your Built-in Ethernet connection to computers using Airport. As I mentioned previously, this will create the new network and also start a DHCP server.
4. On the MacBook, set the Airport network to "Use DHCP". Leave all fields blank.
5. On the MacBook, connect to the newly created network, which should be named "hostname-ics" if you followed my naming advice earlier. Watch the network configuration. Eventually it shows the IP 10.0.2.2.

That's it. You should now have access to your other machines on your private network, but also to Internet.

I had seen somewhere that you could get the 403 error if you were using SSL (which I was) and the Sourceforge server svn.sourceforge.net. The correct server is the PROJECTNAME.svn.sourceforge.net, where PROJECTNAME in my case was springframework. So the correct URL to use is https://springframework.svn.sourceforge.net/svnroot/springframework/. This meant changing the checkout URL, which Subversion can do on an already checked-out working copy, using the switch command. Cool. When I tried this, it failed because it couldn't find the new server. The problem was that the DNS servers I was using at some point didn't find this server, and probably cached this negative hit. Eventually I found a DNS that could locate this server and performed the switch. Things have been working much better since.

Using the incorrect server, which most likely is a proxy server of some sort, could possibly have resulted in different physical servers being used for different requests during the Subversion transaction. It's not allowed to perform a svn copy operation between repositories. You'll get a 403 if you try it. Perhaps that rule applied to my situation as well.

Note that although this follows the Internet standard for email addresses (RFC 822), some sites simply ignore this and incorrectly disallows addresses with plus signs.

Read more here. More cool mail tips can be found here.