Targeting to publish postgis and jts parser relases to Central maven repository

[bergun]

On each release of postgis will automatically publish our jdbc and jts parser releases to Central Maven repository.

[bergun]

​https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

[nicolasf]

I vote for this publication as our open source software(www.orbisgis.org) need an updated driver.

[bergun]

Git patch I prepared for Git mirror.

[bergun]

I have prepared a patch for git mirror

Please test the 2626.patch with:

git apply —stat 2626.patch

and apply the patch with

git am —signoff < 2626.patch

[bergun]

One side note: The jar version is 2.1.0 in the patch. It has to be changed to the latest planned version. Properties will not be allowed in version tag in future maven releases so I omited them.

[pramsey]

You say there's a hardcoded version # in the pom? That kind of implies we need to generate the pom in ./configure to reflect the current version number, so we'll have a pom.xml.in and pom.xml becomes generated. Do we really need to do that? How critical is having a version number in there?

[bergun]

See

[WARNING] 'version' contains an expression but should be a constant. @ org.postgis:postgis-jdbc:${POSTGIS_MAJOR_VERSION}.${POSTGIS_MINOR_VERSION}.${POSTGIS_MICRO_VERSION}, /storage/software/postgis/postgis/java/jdbc/pom.xml

and also

[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.

I will try to find a best practice on version number management during release on pom.xml.

[bergun]

With maven release plugin the below steps are performed inorder to deploy a jar to Central Maven repository:

ALTERNATIVE-1

mvn release:clean release:prepare release:perform

The release:prepare basically:

Check that there are no uncommitted changes in the sources
Check that there are no SNAPSHOT dependencies
Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
Transform the SCM information in the POM to include the final destination of the tag
Run the project tests against the modified POMs to confirm everything is in working order
Commit the modified POMs
Tag the code in the SCM with a version name (this will be prompted for)
Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
Commit the modified POMs

And with mvn release:perform

Checkout from an SCM URL with optional tag
Run the predefined Maven goals to release the project (by default, deploy site-deploy)

For the above procedure my concerns are:

1-) postgis has its own releasing and tagging mechanism. All the sources are in the same repository ie C Java. Since tagging takes place for releasing postgis server codes (C codes); Java codes stays in a position to reuse the existing tagging and releasing mech. In order to be able to use the suggested procedure of maven and OSSRH it looks like Postgis java sources should be separated to a SCM repo for only Java codes.

2-) The one who is responsible for deploying postgis jars to OSSRH repository will need to have SCM write priviledges.

ALTERNATIVE-2

Hold on nothing is over yet There is another approach for releasing which is described 7b. Stage Existing Artifacts in ​https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide

But this alternative approach we need to have a pom.xml as described in 6. On the existing pom.xml we receive a lot of maven warnings and it is not compliant to what is described in 6. So the patch I offer we will need to apply. Though when we apply this patch because we will have hard coded version numbers in pom.xml we will have to maintain the similar procedure as mvn release:prepare does in existing postgis release scripts.

So we need to decide which alternative to go for and than take necessary actions accordingly.

Waiting for ur comments

[robe]

Pushing this one to 2.2.0 since it seems to be a more involved effort and cluttering up the PostGIS 2.1.2 stream.

[bergun]

Hi robe;

I was aware of these things and posted the below mail to Postgis Developer Group:

As described in the http://trac.osgeo.org/postgis/ticket/2626 issue I am trying to reestablish the process of publishing postgis-jdbc and jtsparser to Central Maven repository.

The best way to do this is ALTERNATIVE-1 described in the issue but for that purpose we will need a separate repository for java projects. Basically because with maven deploy and release plugins; all the release and publishing process can be done straight forward. And that maven integrates with SCM for tagging etc. Please read the issue.

Until the above structure can be achieved I can follow ALTERNATIVE-2 procedure can be followed. Though I had to remove below lines from pom.xml; because maven gives warning for the use of properties in the version tag, and that I must have a pom.xml declared as in OSSRH guide(link provided in the issue)

<properties>
    <POSTGIS_MAJOR_VERSION>2</POSTGIS_MAJOR_VERSION>
    <POSTGIS_MINOR_VERSION>1</POSTGIS_MINOR_VERSION>
    <POSTGIS_MICRO_VERSION>0SVN</POSTGIS_MICRO_VERSION>
  </properties>

So I think release scripts are updating properties from pom.xml and on the next release script running it might fail. (If there is such a script as I guess). If you let me know about the scripts I may try to update them or alternatively you let me know about the next release date and the designated version number I will update the version number manually for this time only…

So I wanted to bring these to ur attention for u to understand what might have been broken. Meanwhile I will try to see what I can do for PostGIS 2.1.2.

There is a clash between postgis release mechanism and maven recommended release mechanism for being able to publish to OSSRH (Sonatype Central Repository).

We will need to increase communication with u guys to overcome this situation.

[robe]

bergun,

agreed for now just hard-code the version to 2.1.2 for the 2.1 branch. Still hoping to release in next 2-3 weeks.

Regarding the larger issue if we need a separate repository for Java, would github work okay? We've been slow moving PostGIS to github, though we do have a github mirror that strk manages mirroring: ​https://github.com/postgis . I'm thinking it might not make much sense to manage jdbc in svn if our preferred is github and we need a separate repo for it already. Anyway agree something we need to discuss more on postgis-dev or code sprint

[bergun]

Hi robe;

I think there is a notification problem in my mail settings for trac I have just noticed your reply. I will hard code the version 2.1.2 in the 2.1-branch. And will also update the version to 2.2.0SVN on trunk.

I agree for a separate repository for Jdbc and other java projects on github. This way I can also more easily manage publish jdbc and other jars on OSSRH (maven provides a good release mechanism already).

Replying to robe:

bergun,

agreed for now just hard-code the version to 2.1.2 for the 2.1 branch. Still hoping to release in next 2-3 weeks.

Regarding the larger issue if we need a separate repository for Java, would github work okay? We've been slow moving PostGIS to github, though we do have a github mirror that strk manages mirroring: ​https://github.com/postgis . I'm thinking it might not make much sense to manage jdbc in svn if our preferred is github and we need a separate repo for it already. Anyway agree something we need to discuss more on postgis-dev or code sprint

[kohenkatz]

Has there been any activity on this since last April (the last message I could find on the mailing list that references it)?

[strk]

Hard-coded version remained in the code, and ended up wrong in 2.1.5 release. See ​http://lists.osgeo.org/pipermail/postgis-users/2015-March/040269.html

Was there a plan to fix that hard-coding ?

[bergun]

No activity since than the target version can be updated manually before each release.

[strk]

In that case the HOWTO_RELEASE file should be updated to add the additional manual step. But.. does the ant build do the right thing instead? That's the kind of build you get by running "make" under the jdbc directory.

[strk]

Please see how you like r13337 in trunk. It generates pom.xml from pom.xml.in, automatically substituting the version string from the actual version.

If it's ok to you, I'll backport to the 2.1 branch too.

[strk]

Got into 2.1 branch (2.1.7dev) with r13346. It was an accident, but I'll assume it's ok and keep it there. Original reporter please close if we're done here, or scream if anything was broken

[robe]

this is spun off as it's own project on github, not part of PostGIS core anymore. I'm closing this all future tickets about this should be posted to - ​https://github.com/postgis/postgis-java/issues