Re: Migration to Maven

On 28 November 2015 at 16:00, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)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".
>
> 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?
>

This seems the cleanest. Although I wouldn't be surprised to find issues
down the road. But I would expect that with all of the proposals.

>
> 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.
>

IMO, C is much more work, so I would definitely not vote for this

Dave Cramer

davec(at)postgresintl(dot)com
www.postgresintl.com