Repository files navigation

The repository is archived, and it isno longer used.

This repository includes Maven parent poms that are were by PostgreSQL JDBC driver REL9.4.1207..REL42.2.12.

As pgjdbc switched to Gradle, this repository is no longer used.

You probably do not need to clone/build this repository.In order to contribute a feature / file a bug report for JDBC driver, please useJDBC driver main repository.

In case base dependency (e.g.maven-compiler-plugin version) needs to be changed, a relevant change to thepgjdbc-parent-poms repository shouldbe made and this new version should be used in mainpgjdbc repository.

Most people do not need to compile PgJDBC. You can download prebuilt versions of the driverfrom thePostgresql JDBC site or using your chosen dependency management tool(see details atJDBC driver )

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-parent-poms.git

This will create a pgjdbc-parent-poms directory containing the checked-out source code.

After checking out the code you can install new poms to your local repository:

mvn install

Git repository typically contains -SNAPSHOT versions, so you can use the following command:

mvn deploy

Procedure:

To commit updates to version inpom.xml files and create a tag, issue:

mvn release:clean release:prepare

To stage the version to maven central, issue:

mvn release:perform

This will open staging repository for smoke testing access athttps://oss.sonatype.org/content/repositories/orgpostgresql-1082/

If staged artifacts look fine, release it

mvn nexus-staging:release -DstagingRepositoryId=orgpostgresql-1082

pgjdbc-parent-poms has little to no dependencies itself. It just lists defaults to be used by corepgjdbc project.

PgJDBC development is carried out on thePgJDBC mailing list and onGitHub.

For bug reports please post on pgsql-jdbc or add a GitHub issue. If you includeadditional unit tests demonstrating the issue, or self-contained runnable testcase including SQL scripts etc that shows the problem, your report is likely toget more attention. Make sure you include appropriate details on yourenvironment, 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, feelfree to send a GitHub pull request or post the patch on the PgJDBC mailinglist. Make sure your patch includes additional unit tests demonstrating andtesting any new features. In the case of bug fixes, where possible include anew unit test that failed before the fix and passes after it.

For information on working with GitHub, see:http://help.github.com/articles/fork-a-repo andhttp://learn.github.com/p/intro.html.

Remember to test proposed PgJDBC patches when running against older PostgreSQLversions 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 versionmay use features from that version of the language. i.e. JDBC4.1 specificmay 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 oropen a detailed, specific GitHub issue.

Think about how the change would affect other users, what side effects itmight have, how practical it is to implement, what implications it wouldhave for standards compliance and security, etc. Include a detailed use-casedescription.

Few of the PgJDBC developers have much spare time, so it's unlikely that youridea will be picked up and implemented for you. The best way to make sure adesired feature or improvement happens is to implement it yourself. The PgJDBCsources are reasonably clear and they're pure Java, so it's sometimes easierthan you might expect.

It's possible to debug and test PgJDBC with various IDEs, not just withmvn onthe 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 tomorereadable messages that are easy to follow when looking through theproject history. But also,we use the git commit messages togenerate the change log.

Each commit message consists of aheader, abody and afooter. The header has a specialformat that includes atype, and asubject:

<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 easierto 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, missingsemi-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 documentationgeneration

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

###BodyJust as in thesubject, 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.

###FooterThe footer should contain any information aboutBreaking Changes and is also the place toreference GitHub issues that this commitCloses.

PostgreSQL International