From OpenNMS

Compiling and assembling OpenNMS can take quite a lot of time; speed of compiling is an issue usually, although there's some contributing factors.. Here's a bunch of tips and tricks for speeding up your development cycle:

Contents 1 Compiling the webapp for testing 2 Eclipse 3 Running tests 4 GWT 4.1 Permutations 4.2 Optimisations 4.3 gwt-maven-plugin

Compiling the webapp for testing

You can just

cd opennms-webapp 
../compile.pl

Which will recompile just the webapp. Then you can do a quick "deploy" (without a full assemble), with:

rsync -rcv target/opennms-webapp-1.11.0-SNAPSHOT/ ../target/opennms-1.11.0-SNAPSHOT/jetty-webapps/opennms

Assuming you're working on 1-11.0-SNAPSHOT; adjust the versions to match your development version. The -v option makes it verbose and list files it's transferring; I like it cause it gives me an idea what's changed; whether you use it is up to you.

Non .java changes will not need a restart of opennms. By this I mean .htm[l], .js, .jsp, images, and .css files. Java compiled code will require you to restart OpenNMS (unless Jetty has picked up some magic abilities recently)

If you find the rsync deploy not doing what is advertised here, please note it here; it's not well tested yet.

Eclipse

Only import/open the projects you're working on (e.g. opennms-webapp, opennms-services). Just have the ones you're working on. Eclipse load time will be quicker, builds will not head off and recompile everything. And Maven will take care of dependencies to other OpenNMS projects that you're not really interested in directly right now.

Running tests

Running your postgres "data" directory in a ramdisk can be quite helpful for making tests run in a reasonable amount of time (for some tests, it reduces runtime by 4-5 times). This is just a hint; I'm not telling you how to do it, because if you can't figure out how by yourself, you're probably not going to understand the issues and gotchas (which are significant) around it.

GWT

Note: tips here were noted first when there were other problems that caused GWT to recompile repeatedly. They're still valid (i.e. they work), but are only going to be really helpful if you're developing/changing GWT components regularly, or doing full "clean/compile" cycles on a regular basis. If you're just doing normal dev work, they're not going to have a massive effect, and have the chance of going horribly wrong (by committing the temporary development changes to upstream... :-)).

Permutations

GWT takes a lot of time to compile. The primary problem is the number of permutations. GWT compiles one "permutation" for each user agent and language configured. By default (as in OpenNMS), it compiles in english for every user agent it knows about (5 at this writing). If you requested/defined other languages, you'd get a separate permutation for each user-agent/language combination. But, when developing, you're often on a single computer, with a known browser (and you may not even be doing GWT stuff). In this case, find and edit each *.gwt.xml file. Within the <module> tag, add

<set-property name="user.agent" value="gecko1_8"></set-property>

where the value is your browser. The current values available are defined here

HOWEVER: DO NOT COMMIT THIS CHANGE to any repository anywhere. You'll annoy everyone.

Optimisations

By default, GWT does some heavy optimisations. You can reduce/disable those by editing the pom.xml for the project (opennms-webapp, and features/remote-poller-gwt). To the gwt-maven-plugin config, add the draftCompile option, set to true. E.g (with context):

    <plugin>-
       <groupId>org.codehaus.mojo</groupId>
       <artifactId>gwt-maven-plugin</artifactId>
       <configuration>
         <draftCompile>true</draftCompile>
       </configuration>
     </plugin>
     <plugin

Again, DO NOT COMMIT THIS CHANGE to repositories. You will be shot.

gwt-maven-plugin

The released gwt-maven-plugin has some fairly loose code for determining if a GWT module needs to be recompiled. Touching *any* .gwt.xml, *.ui.xml, or *.java file in the entire project that uses gwt-maven-plugin, will cause **all** GWT modules in that project to be recompiled. This is a problem for quick turnaround times, even if you've applied the hacks above.

So, there is an experimental (but seemingly ok) patched version of gwt-maven-plugin available that does a better job. I've sent this patch to the gwt-maven-plugin maintainers, but until they formally release it, here's how to get/apply it:

Download the .tar.gz from here (hosted offsite because it's temporary).

cd ~/.m2/repository/org/codehaus/mojo/gwt-maven-plugin 
tar -xzvf ~/path/to/gwt-maven-plugin-2.3.0-1-SNAPSHOT.tar.gz

creating a 2.3.0-1-SNAPSHOT directory with 4 files in it.

Then edit the top level pom.xml in opennms, and change the version for gwt-maven-plugin to 2.3.0-1-SNAPSHOT. You'll have to keep/maintain this until we get my patch accepted upstream and a new version of gwt-maven-plugin released. DO NOT COMMIT THIS upstream, otherwise you will be hung, drawn, and quartered.