Java JDBC build issues

[fake]

hi! i just noticed the link to the postgis-2.0.0rc3SVN.jar is 404ing on  http://postgis.refractions.net/download/ - oh noez! :)

[strk]

Confirmed, all the jar under JDBC SNAPSHOT section are broken.

[chodgson]

This has actually been broken since at lest February. I suspect this may have been when some changes were made to the Java build process, and Hudson never got updated to handle them.

There are actually a few problems here: - Makefile calls ant which uses maven - why do we have ant in the middle? - ant target for building javadocs doesn't work - there is a version number in the pom.xml which is improperly defined using variables, and it is not the right version number.

Possible Solutions: - can we get rid of ant and do a pure maven build for the jdbc jar? - can we use autoconf to make a pom.xml from a pom.xml.in, macro-ing in the version number?

Would really like to avoid having the version number sitting in another file. Another alternative is that we don't tie the jdbc version number to the postgis version number, as I suspect that the JDBC isn't updated nearly as often as the rest of the code. But that is actually more work because then we need to make sure the version number for the jdbc IS updated when the JDBC code is, and update the links on the website as well.

[strk]

Yet another solution is that the jdbc stuff is moved completely out of postgis source code. Anyway, this ticket became about java, not management...

[chodgson]

The management issue that remains is that we need valid links on the download page to the jdbc jar and javadocs ... The problem is that the rest of the site is relying on hudson to create and upload such artifacts, but the build for the java stuff isn't quite compatible with how everything else is working. It doesn't have to be hard to fix that, but there may be deeper issues that we may want to resolve - or not.

I do feel that it doesn't make a lot of sense for the java/jdbc stuff to live in the same source repo as the rest of the (c-based) postgis code. Particularly since their life cycles are essentially unrelated at this point. Also, I personally don't use the jdbc code at all even though I do use java to connect to postgis regularly - just use asbinary and the jts wkbreader - but that just means I'm less motivated to do any work on the java build stuff myself.