Tips on Building

Found another one ...

---

I have recently converted the GeoTools build instructions guide to sphinx:

• building

I mostly focused on just porting the content that was there. ;There are a couple interesting observations to be made when picking up a long running document on the Internet.

That was Then

Back when that document was written (say 2003) the internet was a less consistently useful place. ;GeoTools with its habit of using new tools (maven!) new techniques (refactoring!) and new ideas (factory pattern) was often needed to serve as an initial orientation for developers in addition to documenting the running of the project.

This is now

These days we would not bother to explain, after all stack overflow is a click away:

• stackoverflow.com geotools
• stackoverflow.com maven
• stackoverflow.com refactoring
• stackoverflow.com design-patterns

Never the less I picked up a few build tips which you may find useful next time your build GeoTools.

Resuming a build or checkout

I have recently converted the GeoTools developers guide to Sphinx:
- http://docs.geotools.org/latest/developer/

I mostly focused on just porting the content that was there. There  are a couple interesting observations to be made when picking up a long running document on the Internet.

Back when that document was written (say 2003) the internet was a less consistently useful place. GeoTools with its habit of using new tools (maven!) new techniques (refactoring! testing!) and new ideas (factory pattern) was often needed to serve as an initial orientation for developers in addition to documenting the running of the project.

These days we would not bother to explain, after all stack overflow is a click away. (Update: apparently all the cool kids are on gis.stackexchange.com).

Never the less I picked up a few build tips.

Restarting Build

Part of the joy of living in Australia is the consistently amusing weather. For hackers this can result a tendency for long running builds deploys or checkouts to be interrupted by fire or flood. Little did I know that the developers guide indicated how to restart a build.

More realistically it is nice to build with -o (for offline) in order to go a bit faster.

> mvn install -o -Dall
  (failure due to missing jar when building modules/library/data )
> mvn install -rf modules/library/data

Restarting GIT SVN
In a related note if you are using "git svn" and have your initial clone fail 1/2 way through. You can resume using git fetch:

> git svn clone http://svn.osgeo.org/geotools/trunk/
  (fail due to network connection dropping out)
> cd trunk
> git svn fetch

Using Maven to Work with Others

I have watched a number of developers fall over the handling of Maven SNAPSHOTS today; so it was time to take action.

The general idea is an email is sent out saying "new snapshot deployed please build with -U" - here is what that means:

1. Update

   svn up

2. build using the -U option

   mvn clean install -U -Dmaven.test.skip=true

The above example skipped the tests (which is common when you are trying to pull down a quick update and keep working), please note by definition that "-U" is not compatible with the "-o" offline mode.

If you are working on uDig there is an extra step; you need to run the libs refres.xml script which will use a "maven ant task" to pull the changed jars in for your.

Documentation harmed in the making of this post:

• Working With Others (GeoTools Developers Guide)