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:
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.
Running the webapp in place
You can reduce your roundtrip-time developing the webapp by using the ./runInPlace.sh script in the opennms-webapp module. runInPlace uses ./compile.sh to build the webapp and start a jetty via maven. The jetty is configured to rescan the Since the jetty uses a different port then the opennms default port you don't even have to stop your opennms instance.
Make sure you have a build and assembled opennms project by running ./compile.pl and ./assemble.pl. Goto ./opennms-webapp and run
opennms-webapp# ./runInPlace.sh -b.
Now you should have a jetty running on port 8080 which uses
as war content and
as opennms home directory.
To get the webapp redploy and test your changes can can either do
opennms-webapp# mvn clean install
or use hotswap of the java vm by running runInPlace with -t and connect your IDE to the debug port (8002).
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 that require the database
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.
Upgrading to PostgreSQL 9.0+ also significantly reduces the time to run tests because creating databases seems to be much quicker in PostgreSQL 9.0+ and we create hundreds of temporary databases as the tests run.
NOTE: These tips are no longer applicable because Ben tweaked the GWT builds so that only one permutation is built. This makes the GWT and Vaadin builds much quicker so you're not likely to need these tips any more. 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... :-) ).
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
WARNING: DO NOT COMMIT THIS CHANGE to any repository anywhere. You'll annoy everyone.
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.
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.