Thread: Migration to Maven

Hello,

I would like to ask migration about build system from ant to maven.

According to github (https://github.com/pgjdbc/pgjdbc/pull/322) there is some work behind it.

Anyway what do you think about creating profiles in ant/maven?

For example profile where sspi and osgi would be optional.

+ Would you accept patch implementing class which would just has methods from SSPIClient.java and throws unsupported
exception(Real implementation would be in class which inherit from this simple class). 

After proposed changes GNU/Linux distributions (namely fedora) should stick close to upstream without any bigger
patchesor hacks. 

Let me know.

Pavel Kajaba

> Our bigger problem is to figure out how to have JDK 1.6, 1.7, and 1.8 and
> ... all supported by one codebase

Isn't that what the '-source' and '-target' flags for javac are meant
to help solve?

https://maven.apache.org/plugins/maven-compiler-plugin/examples/set-compiler-source-and-target.html

-Adam

On 26-11-2015 18:03, Adam Brightwell wrote:
 >> Our bigger problem is to figure out how to have JDK 1.6, 1.7, and
1.8 and
 >> ... all supported by one codebase
 >
 > Isn't that what the '-source' and '-target' flags for javac are meant
 > to help solve?

That only helps if you are compiling the same software for different
Java versions (and then it would suffice to just target Java 6, as Java
6 bytecode can also be run on newer Java versions).

Also, if you use any new feature in the API, then compiling this way
will lead to a false sense of security as a Java 7 compiler set to
-source and -target 1.6 will **not** detect that you used new classes or
methods (unless you explicitly specify a bootclasspath that points to
the Java 6 runtime classes).

The main problem however is that Java 6 is JDBC 4.0, Java 7 JDBC 4.1 and
Java 8 JDBC 4.2. Each new version added new methods and requirements. If
I recall correctly it should be possible to compile JDBC 4.1 compliant
code with Java 6 (there might be some edge cases), however JDBC 4.2
added a number of new methods that take the SQLType interface, which was
added in Java 8. On top of that, JDBC 4.2 compliance requires
implementation of java.time support on get/setObject in
PreparedStatement and ResultSet. Java.time was also introduced in Java 8.

This makes it impossible to compile the same code for Java 6 and Java 8.
You need to do some form of preprocessing, or selecting/combining
version dependent sourcetrees.

Mark
--
Mark Rotteveel

Gentlemen, are there volunteers to rebase PR 322 onto current master?
Merge conflicts in *.po files scary me a bit.

Well, I can try prototype "pre-processing" approach on top of current
322, however it would be better to rebase first.
Vladimir

I'll rebase it this evening. I'm just not confident the preprocessing will solve all the issues particularly around deploying multiple artifacts to Maven Central.

I might produce another branch which uses Markus's idea to create a branch per spec version. Plus points include making the build script simpler. Minus points are the duplication and possible difficulties backporting fixes.

On 26-11-2015 19:37, Dave Cramer wrote:
> new methods would be OK, as older JDBC versions would never call them,
> but the import for Java.time fails

The import for java.sql.SQLType will also fail. But lets not repeat the
discussion we had a few months back ;)

Mark
--
Mark Rotteveel

On Thu, Nov 26, 2015 at 7:33 PM, Dave Cramer <pg@fastcrypt.com> wrote:
> Thanks Stephen!
>
>

No probs. I've re-based the changes, but don't have the time left to
try the pre-processing or branching.

Vladimir (or anyone), if you want to fork my branch to try the
pre-processing feel free.

I'll try and spend a bit more time at the weekend.

Thanks

Stephen

Thanks Stephen.

Here's my take on pre-processing approach:
https://github.com/pgjdbc/pgjdbc/pull/435

It seems to compile and pass the tests. "release procedure" is to be
checked (set of generated artifacts, naming, versions, etc).

Here's how a section is made "optional for jdbc 4.2 only":

https://github.com/pgjdbc/pgjdbc/blob/2069770c95632118b76fa2fc9229c2f3666e46f4/src/main/java/org/postgresql/jdbc/PgResultSet.java#L304-L320

Vladimir

The main problem with release is maven does not allow multiple deploys
to the same groupId:artifactId:version.

In other words:
1) build via jdk8, deploy -> ok, pom.xml, jdbc42.jar in maven
2) build via jdk7, deploy -> fail: "the same pom.xml already exists".

Well, that is exact problem predicted by Stephen, and I learned it the hard way.

I see two ways to workaround that.
I'm more inclined to "A": drop classifiers and put spec version to the
artifactId.
Any thoughts?

Frankly speaking I see absolutely no problems with having different
artifactIds for different jdbc versions provided github readme gives
<dependency> snippets for jdk6, 7, and 8.

A) Hidden maven submodules with jdbcspec (or jdk version) in
artifactId to provide jdk6&7 artifacts.

A1) mvn release:prepare release:perform via jdk8, deploy -> ok,
pom.xml, postgresql-9.4-1207.jar, postgresql-9.4-1207-sources.jar, etc
in maven. git tag is created for "non-snapshot" version.
A2) build & deploy "hidden" module. It will copy sources&tests from
the main one and build & deploy as usual. The only difference is
"hidden module" should use another maven coordinates. For instance
gorupId=org.postgresql, artifactId=postgresql-jdbc41

This seem to avoid usage of classifiers, and enables to have all three
jars present at the same time (mvn clean would clean just a submodule,
not all of them).

B) Use the same group&artifact and use classifiers to distinguish jdbc
spec versions. Custom-written "deploy-file" calls in profiles for old
JDBC spec versions can deploy additional files without clashing on
pom.xml.
Well, we could integrate custom deploy-file calls, but maven cannot
locate source.jar if custom classifiers are used (maven always
searches for ${artifact}-${version}-sources.jar).
That means we cannot have source.jar per jdbc spec, that is sad from
user-perspective.

B1) == A1, except classifiers are used.
B2) checkout non-snapshot tag, build only "core" project via jdk7. It
skips "default-deploy" and uses deploy-file tasks to deploy
jdbc41.jar, jdbc41-sources.jar, etc to maven.
B3) the same for jdk6
The trick is generatePom=false allows to deploy just a file without
overwriting pom.xml.
Final repository has all the jars under
org.postgresql:postgresql:9.4-1207 with different classifiers.

C) Branch per spec. Well, that seems to be harder to maintain as it
would require back-patching the same changes over and over.
It does not solve "same pom.xml" deployment problem, thus "branch per
spec" must be combined with A or B.

Vladimir

I'm always a friend of clean and CoC-alike solutions. Hence I'd say it would be best to use the artifactId to indicate
thedifference between the JARs: A JDBC42 driver is definitively something different than a JDBC3 driver, so it would be
wrongto use the same artifact name. 

Anyways, my personal favorite is not liked by the project lead: Do not backport features into old PostgreSQL versions.
Thatmeans, for each supported version of PostgreSQL there is one single branch, and that branch supports only the JDBC
/JDK combination which was current at time of publication of the JDBC version. Into that branches, only backport fixes,
whichis simply using git. New features (and such, new JDBC / JDK combinations) on are added to that single JAR for the
NEXTplanned PostgreSQL version. This cuts away a lot of branches which nobody ever will need. PostgreSQL itself also
doesnot add new technology to old versions, so why do we? 

-Markus

-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Vladimir Sitnikov
Sent: Samstag, 28. November 2015 22:01
To: Stephen Nelson; List
Subject: Re: [JDBC] Migration to Maven

The main problem with release is maven does not allow multiple deploys
to the same groupId:artifactId:version.

In other words:
1) build via jdk8, deploy -> ok, pom.xml, jdbc42.jar in maven
2) build via jdk7, deploy -> fail: "the same pom.xml already exists".

Well, that is exact problem predicted by Stephen, and I learned it the hard way.

I see two ways to workaround that.
I'm more inclined to "A": drop classifiers and put spec version to the
artifactId.
Any thoughts?

Frankly speaking I see absolutely no problems with having different
artifactIds for different jdbc versions provided github readme gives
<dependency> snippets for jdk6, 7, and 8.

A) Hidden maven submodules with jdbcspec (or jdk version) in
artifactId to provide jdk6&7 artifacts.

A1) mvn release:prepare release:perform via jdk8, deploy -> ok,
pom.xml, postgresql-9.4-1207.jar, postgresql-9.4-1207-sources.jar, etc
in maven. git tag is created for "non-snapshot" version.
A2) build & deploy "hidden" module. It will copy sources&tests from
the main one and build & deploy as usual. The only difference is
"hidden module" should use another maven coordinates. For instance
gorupId=org.postgresql, artifactId=postgresql-jdbc41

This seem to avoid usage of classifiers, and enables to have all three
jars present at the same time (mvn clean would clean just a submodule,
not all of them).

B) Use the same group&artifact and use classifiers to distinguish jdbc
spec versions. Custom-written "deploy-file" calls in profiles for old
JDBC spec versions can deploy additional files without clashing on
pom.xml.
Well, we could integrate custom deploy-file calls, but maven cannot
locate source.jar if custom classifiers are used (maven always
searches for ${artifact}-${version}-sources.jar).
That means we cannot have source.jar per jdbc spec, that is sad from
user-perspective.

B1) == A1, except classifiers are used.
B2) checkout non-snapshot tag, build only "core" project via jdk7. It
skips "default-deploy" and uses deploy-file tasks to deploy
jdbc41.jar, jdbc41-sources.jar, etc to maven.
B3) the same for jdk6
The trick is generatePom=false allows to deploy just a file without
overwriting pom.xml.
Final repository has all the jars under
org.postgresql:postgresql:9.4-1207 with different classifiers.

C) Branch per spec. Well, that seems to be harder to maintain as it
would require back-patching the same changes over and over.
It does not solve "same pom.xml" deployment problem, thus "branch per
spec" must be combined with A or B.

Vladimir


--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

On Sat, Nov 28, 2015 at 9:00 PM, Vladimir Sitnikov
<sitnikov.vladimir@gmail.com> wrote:
> The main problem with release is maven does not allow multiple deploys
> to the same groupId:artifactId:version.
>
> In other words:
> 1) build via jdk8, deploy -> ok, pom.xml, jdbc42.jar in maven
> 2) build via jdk7, deploy -> fail: "the same pom.xml already exists".

I'm not glad it happened, but glad that you experienced the same issue as me!

I think the Ant build was hiding the fact we do have three different
artifacts but managed to combine them into the same co-ordinates in
Maven Central.

> Frankly speaking I see absolutely no problems with having different
> artifactIds for different jdbc versions provided github readme gives
> <dependency> snippets for jdk6, 7, and 8.

Agreed.

My preference is option C if it is not too onerous, followed by option A.

Option C would appear the cleaner approach, but has the downside or
creating additional workload on a small team. Can we quantify how
difficult would it be to backport fixes?

If the structure of the projects is exactly the same it should be
possible to cherry-pick the commits. If we keep to a standard of using
JDK6-compatible code where possible the branches shouldn't drift too
far from each other. The other benefit is that the pom.xml will be
simpler without all the build profiles and multi-module build.

If not option A seems sensible and will allow us to publish complete
sources, javadoc and the artifact that all correspond to the spec
version.

>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

On Nov 30, 2015, at 1:18 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
>
> 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.
>

Here is an example of how we did it in another project, in case that is helpful:
https://github.com/jdbi/jdbi/pull/169/files

> 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

It would be nice for this to be one step, if possible... just wait until someone
does a typo on one of the versions :)

Sorry for top posting but using a mobile device.

There is a Maven plugin Animal Sniffer to check if you are breaking JDK compatibility.

I'm happy with either option so let's get this PR merged before the end of 2015!

On Mon, 30 Nov 2015, 21:18 Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:

>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

>So where are we on this? Do you feel we are ready to commit this ?

File/folder structure -- almost done.
I would be happy if someone reviews that.

Tests need to be corrected: they rely on filesystem (e.g.
ssltest.properties, etc, etc), so it should be fixed.
I'll notify as I get that fixed.

Vladimir

We are trying to build RPM package for postgresql-JDBC.

There is no SSPI and OSGi package in Fedora so we are unable to build it.

SSPI is totally useless since it's just Windows thing. OSGi has problematic licence, but after doing some research it's
notrequired to run postgresql-JDBC. 

We believe that it would be really great for Fedora (also other distros - lot of things depends on your great work) if
Wecould manage to make these two components optional. 

After doing some research and talk with Java friends, there is a way how to make it optional during build time.

Profiles - both ant and Maven has them, but in case of migrating to Maven, I think it would be waste of time to create
patchfor ant profile since it would just throw away. 

Let me know your thoughts about this.

Thanks!

Pavel Kajaba.

----- Original Message -----
From: "Dave Cramer" <pg@fastcrypt.com>
To: "Pavel Kajaba" <pkajaba@redhat.com>
Cc: "List" <pgsql-jdbc@postgresql.org>, "Pavel Raiskup" <praiskup@redhat.com>
Sent: Thursday, November 26, 2015 1:20:03 PM
Subject: Re: [JDBC] Migration to Maven

On 26 November 2015 at 04:29, Pavel Kajaba <pkajaba@redhat.com> wrote:

> Hello,
>
> I would like to ask migration about build system from ant to maven.
>
> According to github (https://github.com/pgjdbc/pgjdbc/pull/322) there is
> some work behind it.
>
> Anyway what do you think about creating profiles in ant/maven?
>

What problem are you trying to solve ?

Our bigger problem is to figure out how to have JDK 1.6, 1.7, and 1.8 and
... all supported by one codebase

Dave Cramer

davec@postgresintl.com
www.postgresintl.com


>

>There is no SSPI and OSGi package in Fedora so we are unable to build it.

Can you clarify what do you mean by "unable to build"?
Vladimir

Fedora packages are build offline and all binary files (jars and class files) are removed - simply all dependencies
haveto be obtained from software, which is packed in Fedora already. 

So it fails on missing SSPI and OSGi imports.

----- Original Message -----
From: "Vladimir Sitnikov" <sitnikov.vladimir@gmail.com>
To: "Pavel Kajaba" <pkajaba@redhat.com>
Cc: "Dave Cramer" <pg@fastcrypt.com>, "List" <pgsql-jdbc@postgresql.org>, "Pavel Raiskup" <praiskup@redhat.com>
Sent: Wednesday, December 2, 2015 8:37:09 AM
Subject: Re: [JDBC] Migration to Maven

>There is no SSPI and OSGi package in Fedora so we are unable to build it.

Can you clarify what do you mean by "unable to build"?
Vladimir


--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

Can you share a build log of the build in question?
Can the issue be reproduced on Travisci?
Do you have a public CI that reproduces the issue?

Can you try building https://github.com/pgjdbc/pgjdbc/pull/435 in your
environment and check if that works?

Do you have a development guide on "writing Fedora-compatible build
scripts for java libraries"?

Vladimir

On Wednesday 02 of December 2015 02:49:07 Pavel Kajaba wrote:
> Fedora packages are build offline and all binary files (jars and class
> files) are removed

Just to give it some reasoning.

We remove all (program/code) binary files from upstream tarballs, because
you simply (a) *can't be sure* what the binary does and (b) you can't tell
whether licensing is not broken (we need to be sure we can legally
re-distribute).

> simply all dependencies have to be obtained from software, which is
> packed in Fedora already.

Yes, either package must be built completely from source, or we may use
our other already distributed packages as dependencies (which already
_must_ built from source too).

Downloading some binary jars from internet is not acceptable.  Fedora is
not alone -- this issue probably blocks all (sane) FOSS distributions
around.

Pavel

Can you advice us how to make it optional? If we did not provided required files build errors occurred.

We were able to build it, but we had to delete all source files, which required OSGi imports and edit build.xml.
HoweverI doubt this is appropriate solution. 

Pavel Kajaba.

----- Original Message -----

From: "Balázs Zsoldos" <balazs.zsoldos@everit.biz>
To: "List" <pgsql-jdbc@postgresql.org>
Sent: Wednesday, December 2, 2015 9:30:16 AM
Subject: Re: [JDBC] Migration to Maven




OSGi has problematic licence


All OSGi jars are licensed with Apache 2.0. Is it problematic?




OSGi is an optional dependency for postgresql jdbc driver. It is only
necessary if someone uses the driver within an OSGi container. I think it
is hardly the case when someone wants to use it from a linux package
management system. That means that osgi jars do not have to be on the
classpath at runtime when monolith application is started. I do not know
this Fedora solution, but isn't is possible to ignore this dependency in
the Fedoray package management after building the jar?

*Zsoldos Balázs*
Rendszertervező | Software architect


+36 70 594 9234 | balazs.zsoldos@everit.biz

*EverIT Kft.*
1137 Budapest, Katona József utca 17. III. em. 2.
http://www.everit.biz I info@everit.biz


Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem alatt
áll, a nyilvános közléstől védett. Az üzenetet kizárólag a címzett, illetve
az általa meghatalmazottak használhatják fel. Ha Ön nem az üzenet
címzettje, úgy kérjük, hogy telefonon, vagy e-mail-ben értesítse erről az
üzenet küldőjét és törölje az üzenetet, valamint annak összes csatolt
mellékletét a rendszeréből. Ha Ön nem az üzenet címzettje, abban az esetben
tilos az üzenetet vagy annak bármely csatolt mellékletét lemásolnia,
elmentenie, az üzenet tartalmát bárkivel közölnie vagy azzal visszaélnie.


This message and any attachment are confidential and are legally
privileged. It is intended solely for the use of the individual or entity
to whom it is addressed and others authorised to receive it. If you are not
the intended recipient, please telephone or email the sender and delete
this message and any attachment from your system. Please note that any
dissemination, distribution, copying or use of or reliance upon the
information contained in and transmitted with this e-mail by or to anyone
other than the recipient designated above by the sender is unauthorised and
strictly prohibited.

On Wed, Dec 2, 2015 at 8:24 AM, Pavel Kajaba <pkajaba@redhat.com> wrote:


<blockquote>
We are trying to build RPM package for postgresql-JDBC.

There is no SSPI and OSGi package in Fedora so we are unable to build it.

SSPI is totally useless since it's just Windows thing. OSGi has
problematic licence, but after doing some research it's not required to run
postgresql-JDBC.

We believe that it would be really great for Fedora (also other distros -
lot of things depends on your great work) if We could manage to make these
two components optional.

After doing some research and talk with Java friends, there is a way how
to make it optional during build time.

Profiles - both ant and Maven has them, but in case of migrating to Maven,
I think it would be waste of time to create patch for ant profile since it
would just throw away.

Let me know your thoughts about this.

Thanks!

Pavel Kajaba.

----- Original Message -----
From: "Dave Cramer" <pg@fastcrypt.com>
To: "Pavel Kajaba" <pkajaba@redhat.com>
Cc: "List" <pgsql-jdbc@postgresql.org>, "Pavel Raiskup" <
praiskup@redhat.com>
Sent: Thursday, November 26, 2015 1:20:03 PM
Subject: Re: [JDBC] Migration to Maven

On 26 November 2015 at 04:29, Pavel Kajaba <pkajaba@redhat.com> wrote:

> Hello,
>
> I would like to ask migration about build system from ant to maven.
>
> According to github (https://github.com/pgjdbc/pgjdbc/pull/322) there is
> some work behind it.
>
> Anyway what do you think about creating profiles in ant/maven?
>

What problem are you trying to solve ?

Our bigger problem is to figure out how to have JDK 1.6, 1.7, and 1.8 and
... all supported by one codebase

Dave Cramer

davec@postgresintl.com
www.postgresintl.com


>


--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc



</blockquote>

> However, I would be very disappointed if the OSGi manifest headers disappeared from the JAR file.

Did you just say you know how to test "if OSGi headers are good enough"?

Can you please share that? (e.g. sample maven project that uses OSGi
headers to talk to the driver)
Can you please test if OSGi headers in
https://github.com/pgjdbc/pgjdbc/pull/435 are good enough?

Vladimir

I'm settled on maven migration, so please review
https://github.com/pgjdbc/pgjdbc/pull/435.

It works for me (Mac OS, IDEA, JDK 7/8).
It deploys to local Nexus (however I am unable to perform full testing
against maven central as I do not have enough privileges).
The deployed artifacts support regular "download maven sources" action in IDE.

Vladimir

On Wed, Dec 2, 2015 at 7:36 PM, Dave Cramer <pg@fastcrypt.com> wrote:
> Anyone have any objections to this ? Otherwise I'm going to merge it
> tomorrow
>

Are there any PRs that should be merged in first? This change will
mean all those outstanding PRs will need some work before they build
successfully.

Hello,

how are you progressing with that merge?

Pavel Kajaba.

----- Original Message -----
From: "Dave Cramer" <pg@fastcrypt.com>
To: "Vladimir Sitnikov" <sitnikov.vladimir@gmail.com>
Cc: "List" <pgsql-jdbc@postgresql.org>, "Balázs Zsoldos" <balazs.zsoldos@everit.biz>
Sent: Wednesday, December 2, 2015 8:36:49 PM
Subject: Re: [JDBC] Migration to Maven

Anyone have any objections to this ? Otherwise I'm going to merge it
tomorrow

Dave Cramer

davec@postgresintl.com
www.postgresintl.com

On 2 December 2015 at 11:56, Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
wrote:

> I'm settled on maven migration, so please review
> https://github.com/pgjdbc/pgjdbc/pull/435.
>
> It works for me (Mac OS, IDEA, JDK 7/8).
> It deploys to local Nexus (however I am unable to perform full testing
> against maven central as I do not have enough privileges).
> The deployed artifacts support regular "download maven sources" action in
> IDE.
>
> Vladimir
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>

Here's staging repository for java 8 compatible driver:
https://oss.sonatype.org/content/repositories/orgpostgresql-1084/
It is build from https://github.com/pgjdbc/pgjdbc/tree/REL9.4.1207

I'll gather jars for jre6 and jre7 together tomorrow and if that
works, I'll merge that in.

What I do not like is that build via java7 fails at random:
https://travis-ci.org/pgjdbc/pgjdbc/builds/97856702,
https://travis-ci.org/pgjdbc/pgjdbc/builds/97856670.

Vladimir

I've merged maven PR in.

Thanks everyone who worked on this!
Special thanks goes to Stephen for the initial mavenization.

Travis job would automatically publish snapshots to Central:
https://oss.sonatype.org/content/repositories/snapshots/org/postgresql/postgresql/

Vladimir Sitnikov

On Sun, Dec 20, 2015 at 9:07 PM, Vladimir Sitnikov
<sitnikov.vladimir@gmail.com> wrote:
> I've merged maven PR in.
>
> Thanks everyone who worked on this!
> Special thanks goes to Stephen for the initial mavenization.
>
> Travis job would automatically publish snapshots to Central:
> https://oss.sonatype.org/content/repositories/snapshots/org/postgresql/postgresql/
>
> Vladimir Sitnikov


Hi Vladimir,
Great work - thanks for getting it completed. I know it was a lot of effort.

Many thanks

Stephen.

Kudos to everybody involved! :-)

-Markus

-----Original Message-----
From: pgsql-jdbc-owner@postgresql.org [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Stephen Nelson
Sent: Sonntag, 20. Dezember 2015 23:01
To: List
Subject: Re: [JDBC] Migration to Maven

On Sun, Dec 20, 2015 at 9:07 PM, Vladimir Sitnikov <sitnikov.vladimir@gmail.com> wrote:
> I've merged maven PR in.
>
> Thanks everyone who worked on this!
> Special thanks goes to Stephen for the initial mavenization.
>
> Travis job would automatically publish snapshots to Central:
> https://oss.sonatype.org/content/repositories/snapshots/org/postgresql
> /postgresql/
>
> Vladimir Sitnikov


Hi Vladimir,
Great work - thanks for getting it completed. I know it was a lot of effort.

Many thanks

Stephen.


--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc