>but has the downside or creating additional workload
Another downside is inability to test if PR breaks build for JDK 6.
Note: development of "current" version should be done via JDK8, so it
is super easy to use new APIs by mistake (e.g. Map#replace,
Map#getOrDefault, or whatever).
Current travis CI setup is very good as it provides fast feedback for
different JDKs.
I've updated https://github.com/pgjdbc/pgjdbc/pull/435 to reflect option A.
It does exclude all the testing as I was focused on a release procedure.
It does point to my github fork as release involves git tag/push/etc.
I use the same artifactId, and include JRE to version.
There are two reasons for that:
1) That ensures there will be just a single pgjdbc artifact in classpath
2) It will simplify life for third party projects, as switch from
pgjdbc-jre7 to pgjdbc-jre8 artifactId would require updating of lots
of poms while version can be fixed in a dependencyManagement, thus
there can be a single "9.4-jre7" to "9.4" switch.
maven-toolchains-plugin allows to specify per-module JDK version, so
you just mvn and it uses the proper JDK.
I did not figure proper travis configuration yet, however I think it
should not be hard.
It boils down the release procedure to:
Release for jre8
1) mvn release:clean release:prepare, enter, enter, enter
2) mvn release:perform
Release for jre7
3) cd core-jre7; mvn release:clean release:prepare, enter, type <next
version>; enter, enter
4) mvn release:perform
Release for jre6
3) cd core-jre6; mvn release:clean release:prepare, enter, type <next
version>; enter, enter
4) mvn release:perform
For regular JDK8 development, it does not require you to setup toolchains.xml.
However, if you do, you'll be able to build core-jre7 with a matter of
mvn install (no need to play with java_home).
Vladimir
