New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: migrate build for maven (322 + multi-module + preprocessor) #435

Merged
merged 7 commits into from Dec 20, 2015

Conversation

Projects
None yet
4 participants
@vlsi
Member

vlsi commented Nov 27, 2015

This change migrates build to maven and corrects javadoc warnings.

https://github.com/raydac/java-comment-preprocessor is used to generate JRE6 & JRE7 compatible sources on the fly when building core-jre6 and core-jre7 modules.
The generated sources are placed in core-jre7/target/gen-src and included into -sources.jar.

Even though parents artifacts (there are quite a few of pom.xml files there) might better be placed to its own repository and have their own versions, that would make dependency update harder (it would require PRs to different repositories, separate release process, etc). That is why I decided to keep all modules in the single git repository.

The change is heavily based on #322 by @lordnelson. This PR is a multi-module build, so I squash "#322 mavenization" and "modularization" commits to make git history cleaner in terms of understanding where went each file.

Current status:

  • drop jdbc2, jdbc3, etc packages (rename old org.postgresql.jdbc2 to org.postgresql.jdbc)
  • inline all Abstract... into Pg... classes. For instance, now it reads PgResultSet implements ResultSet
  • add pre-processor step
  • convert old Driver.java, etc templates
  • jdk7
  • jdk6
  • fix javadoc warnings/errors
@vlsi

This comment has been minimized.

Member

vlsi commented Nov 27, 2015

the following code:

    //#if mvn.project.property.postgresql.jdbc.spec >= "jdbc42"
    public void updateObject(int columnIndex, Object x, SQLType targetSqlType, int scaleOrLength) throws SQLException {
        throw Driver.notImplemented(this.getClass(), "updateObject");
    }
    //#endif

results in

    //JCP! if mvn.project.property.postgresql.jdbc.spec >= "jdbc42"
//JCP>     public void updateObject(int columnIndex, Object x, SQLType targetSqlType, int scaleOrLength) throws SQLException {
//JCP>         throw Driver.notImplemented(this.getClass(), "updateObject");
//JCP>     }
    //JCP! endif

So far so good. Line numbers are intact, so exceptions would be easier to read.
I expect "optimize imports" in IDE to break as we would have to have selective imports as well :(
Not sure how bad it would be.

@vlsi vlsi force-pushed the Gordiychuk:pre_processor branch from 4d8e6ec to 006993e Nov 27, 2015

@davecramer

This comment has been minimized.

Member

davecramer commented Nov 27, 2015

I'm wondering do we actually have to comment out everything that is jdbc 4.2 or just comment out uses of classes that previous versions can't import ?

@vlsi

This comment has been minimized.

Member

vlsi commented Nov 27, 2015

is jdbc 4.2 or just comment out uses of classes that previous versions can't import ?

Well, we can stick to "do not use import for classes that do not exist in jre6" convention, so no "import java.time" would be required.

@davecramer

This comment has been minimized.

Member

davecramer commented Nov 27, 2015

Dave Cramer

On 27 November 2015 at 08:46, Vladimir Sitnikov notifications@github.com
wrote:

is jdbc 4.2 or just comment out uses of classes that previous versions
can't import ?

Well, we can stick to "do not use import for classes that do not exist in
jre6" convention, so no "import java.time" would be required.

Would that make things simpler ?


Reply to this email directly or view it on GitHub
#435 (comment).

@vlsi

This comment has been minimized.

Member

vlsi commented Nov 27, 2015

Would that make things simpler ?

I think it would keep import section cleaner.

@davecramer

This comment has been minimized.

Member

davecramer commented Nov 27, 2015

Well I'm just going to stay out of your way. It was just a thought.

Dave Cramer

On 27 November 2015 at 08:50, Vladimir Sitnikov notifications@github.com
wrote:

Would that make things simpler ?

I think it would keep import section cleaner.


Reply to this email directly or view it on GitHub
#435 (comment).

@vlsi vlsi force-pushed the Gordiychuk:pre_processor branch from 006993e to d0ff2f4 Nov 27, 2015

@vlsi

This comment has been minimized.

Member

vlsi commented Nov 27, 2015

I'm a bit surprised, however I had to do no modifications/pre-processing to support jdk6.
So, the only pre-processing required so far is commenting usage of SQLType for java8.

@davecramer

This comment has been minimized.

Member

davecramer commented Nov 27, 2015

That's awesome. Very minimal preprocessing then.

Dave Cramer

On 27 November 2015 at 09:39, Vladimir Sitnikov notifications@github.com
wrote:

I'm a bit surprised, however I had to do no
modifications/pre-processing to support jdk6.
So, the only pre-processing required so far is commenting usage of SQLType
for java8.


Reply to this email directly or view it on GitHub
#435 (comment).

@vlsi vlsi force-pushed the Gordiychuk:pre_processor branch 5 times, most recently from cccbf6d to 3dd0ed8 Nov 27, 2015

@vlsi vlsi force-pushed the Gordiychuk:pre_processor branch 14 times, most recently from 2e1bf42 to 925ab83 Nov 28, 2015

@vlsi vlsi force-pushed the Gordiychuk:pre_processor branch 16 times, most recently from f73ffc3 to d1727c0 Dec 20, 2015

lordnelson and others added some commits Jun 13, 2015

chore: migrate the build to Maven
Use Maven as the build tool to reduce complexity of the build process. Separate source and test into
separate directories according to Maven conventions.

closes #322

@vlsi vlsi force-pushed the Gordiychuk:pre_processor branch from d1727c0 to b8615b7 Dec 20, 2015

vlsi added a commit to Gordiychuk/pgjdbc that referenced this pull request Dec 20, 2015

chore: use java comment preprocessor to build jre6/jre7/jre8 jars fro…
…m the same sources

This enables having a single source file and simple `implements Connection`.
The existing `42Connection extends 41Connection extends ...` is simplified to `PgConnection implements java.sql.Connection`

closes pgjdbc#435

vlsi added some commits Dec 6, 2015

chore: use java comment preprocessor to build jre6/jre7/jre8 jars fro…
…m the same sources

This enables having a single source file and simple `implements Connection`.
The existing `42Connection extends 41Connection extends ...` is simplified to `PgConnection implements java.sql.Connection`

closes #435

@vlsi vlsi force-pushed the Gordiychuk:pre_processor branch from b8615b7 to ed1a916 Dec 20, 2015

vlsi added a commit that referenced this pull request Dec 20, 2015

Merge pull request #435 from Gordiychuk/pre_processor
chore: migrate build for maven

This change migrates build to maven and corrects javadoc warnings when building via java 8.
The updated Travis configuration automatically deploys snapshots to Maven Central

https://github.com/raydac/java-comment-preprocessor is used to generate JRE6 & JRE7 compatible sources on the fly when building pgjdbc-jre6 and pgjdbc-jre7 modules

@vlsi vlsi merged commit 32f5133 into pgjdbc:master Dec 20, 2015

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@davecramer

This comment has been minimized.

Member

davecramer commented Dec 20, 2015

Awesome! Thanks to everyone who worked on this!

Dave Cramer

On 20 December 2015 at 14:57, Vladimir Sitnikov notifications@github.com
wrote:

Merged #435 #435.


Reply to this email directly or view it on GitHub
#435 (comment).

@vlsi vlsi deleted the Gordiychuk:pre_processor branch Dec 22, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment