[sword-devel] sword-devel Digest, Vol 73, Issue 45

Yiguang Hu yighu at yahoo.com
Tue Apr 27 19:17:36 MST 2010


I followed the steps and found the problem is in test and gwt:compile. The following did the trick.
<extraJvmArgs>-Xmx1024M -XstartOnFirstThread -Dconnection.string="${db.connection.string}" -Ddb.driver=${db.driver}</extraJvmArgs>

So Step is build in my local now.

From: Chris Burrell <chris at burrell.me.uk>
To: Yiguang Hu <yighu at yahoo.com>
Cc: SWORD Developers' Collaboration Forum <sword-devel at crosswire.org>; wes at werxltd.com; Brian Jolly <brian at brianjolly.com>
Sent: Tue, April 27, 2010 6:14:50 PM
Subject: Re: [sword-devel] sword-devel Digest, Vol 73, Issue 45

Hi Yiguang

A maven command looks like this:

mvn phase1 phase2 phase3  or mvn plugin:goal

During a build phase, maven invokes a number of plugins. For example, during the compile phase, the java compiler plugin is invoked, the gwt compiler is invoked, etc. So, when you're invoking mvn clean install, it is the same as mvn clean, followed by mvn install

The parent pom.xml defines a number of modules. (<modules> tag) When you invoke mvn clean or mvn install at the top level, all it does is cds into each module in turn, and invokes the same command. The child poms (at the top of the pom) contain the reference to the parent. In a way, the mvn -pl <modulename> clean install command you did earlier last week is the same as cd <modulename> & mvn clean install

clean basically gets rid of all the target folders under each module. When you invoke the build lifecycle (for e.g. install), it does all the phases up-to and including that. 
So mvn install can be broken down as follows

mvn validate
mvn compile
mvn test
mvn package
mvn integration-test
mvn verify
mvn install

but skips the last stage:
mvn deploy

If you're getting a warning about serialization, I reckon you're running out of memory during the GWT compiliation, which happens during the compile phase mentioned above.

To prove this, I think you could try the following. First prove you can successfully build step-dataloader:

1- cd into step-dataloader
2- mvn clean
3- mvn install

[if that works, you've got at least 1 of the 4 modules working!]

4- cd into step-web-app, and run
5- mvn clean
6- mvn compiler:compile (invoking the compile goal on the maven java compiler plugin)
7- mvn gwt:compile (invoking the compile goal on the gwt maven plugin)

The warning (if it's the one I'm thinking of) is fine and due to a library we're using which hasn't been upgraded to GWT 2.0.

I came across this:

which suggests you should try increasing the memory allocated to the gwt:compile. so in your pom.xml, find the gwt compiler plugin (under <build><plugins>, find the plugin called gwt-maven-plugin and under the <extraJvmArguments> specify some good memory arguments, for e.g. 

-Xmx1024M -XstartOnFirstThread

so your tag would like something like:

<extraJvmArgs>-Xmx1024M -XstartOnFirstThread -Dconnection.string="${db.connection.string}" -Ddb.driver=${db.driver}</extraJvmArgs>

Hope that helps. It might be that, because I specified the extraJvmArgs attribute, I lost the default of -Xmx512M and thereby the defaults are the OS defaults. Also, apparently the startOnFirstThread is a Mac OS specific argument which apparently fixes JVM issues on Mac OS Leopard

Hope that helps!

On 27 April 2010 22:27, Yiguang Hu <yighu at yahoo.com> wrote:

>I am on both lists. I have not resolved OOM yet. The OOM happens during mvn clean install (seems it was doing some serialization related things before OOM. And I didn't notice a memory surge during the process). Will look at the pom file to see how to do it by individual modules. (I am new to mvn). It would be great if you can show me how to divide mvn clean install into more steps for building the STEP.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20100427/cbbad275/attachment.html>

More information about the sword-devel mailing list