This repository includes maven project to build Java 7 compatible (JDBC 4.1) PostgreSQL JDBC driver.
There are two major cases you might need to build this repository: you want to build custom Java 7 compatible driver, or you want to release pgjdbc. In order to contribute a feature / file a bug report for JDBC driver, please use JDBC driver main repository.
This repository should store only Java 7 specific configurations. At best, all the configuration should be in pgjdbc-parent-poms.
Most people do not need to compile PgJDBC. You can download prebuilt versions of the driver from the Postgresql JDBC site or using your chosen dependency management tool (see details at PgJDBC driver page )
In order to build the set of parent poms, you will need the following tools:
- A git client
- A recent version of Maven (3.x)
- A JDK (any should work)
The PgJDBC project uses git for version control. You can check out the current code by running:
git clone https://github.com/pgjdbc/pgjdbc.git
cd pgjdbc
git clone https://github.com/pgjdbc/pgjdbc-jre6.git
git clone https://github.com/pgjdbc/pgjdbc-jre7.git
This will create a pgjdbc-jre7 directory that can be used to build Java 7 compatible JDBC driver.
After checking out the code you can build the driver.
cd pgjdbc-jre7
mvn install
# mvn install -DskipTests
# mvn install -P release-artifacts # to build jars with javadocs and sources
Git repository typically contains -SNAPSHOT versions, so you can use the following command:
mvn deploy
Note: full procedure is described in PgJDBC release procedure
Before releasing jre7-compatible version, update pgjdbc submodule to a release version
Update pgjdbc git submodule to current master version:
git submodule update --init
cd pgjdbc
git checkout master
git reset --hard REL9.4.1208
cd ..
git add pgjdbc
git commit -m "Update pgjdbc"
To commit updates to version in pom.xml files and create a tag, issue:
mvn release:clean release:prepare
To release the version to maven central, issue:
mvn release:release
pgjdbc-parent-poms has little to no dependencies itself. It just lists defaults to be used by core pgjdbc project.
PgJDBC development is carried out on the PgJDBC mailing list and on GitHub.
For bug reports please post on pgsql-jdbc or add a GitHub issue. If you include additional unit tests demonstrating the issue, or self-contained runnable test case including SQL scripts etc that shows the problem, your report is likely to get more attention. Make sure you include appropriate details on your environment, like your JDK version, container/appserver if any, platform, PostgreSQL version, etc. Err on the site of excess detail if in doubt.
If you've developed a patch you want to propose for inclusion in PgJDBC, feel free to send a GitHub pull request or post the patch on the PgJDBC mailing list. Make sure your patch includes additional unit tests demonstrating and testing any new features. In the case of bug fixes, where possible include a new unit test that failed before the fix and passes after it.
For information on working with GitHub, see: https://help.github.com/articles/fork-a-repo.
Remember to test proposed PgJDBC patches when running against older PostgreSQL versions where possible, not just against the PostgreSQL you use yourself.
You also need to test your changes with older JDKs. PgJDBC must support JDK6 ("Java 1.6") and newer. Code that is specific to a particular spec version may use features from that version of the language. i.e. JDBC4.1 specific may use JDK7 features, JDBC4.2 may use JDK8 features. Common code and JDBC4 code needs to be compiled using JDK6.
If you have ideas or proposed changes, please post on the mailing list or open a detailed, specific GitHub issue.
Think about how the change would affect other users, what side effects it might have, how practical it is to implement, what implications it would have for standards compliance and security, etc. Include a detailed use-case description.
Few of the PgJDBC developers have much spare time, so it's unlikely that your idea will be picked up and implemented for you. The best way to make sure a desired feature or improvement happens is to implement it yourself. The PgJDBC sources are reasonably clear and they're pure Java, so it's sometimes easier than you might expect.
It's possible to debug and test PgJDBC with various IDEs, not just with mvn on
the command line. Projects aren't supplied, but it's easy to prepare them.
We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate the change log.
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, and a subject:
<type>: <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on github as well as in various git tools.
Must be one of the following:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug or adds a feature
- perf: A code change that improves performance
- test: Adding missing tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
The subject contains succinct description of the change:
- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize first letter
- no dot (.) at the end
###Body Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes" The body should include the motivation for the change and contrast this with previous behavior.
###Footer The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.