[postgis-tickets] [PostGIS] #2626: Targeting to publish postgis and jts parser relases to Central maven repository

PostGIS trac at osgeo.org
Thu Feb 20 12:12:53 PST 2014


#2626: Targeting to publish postgis and jts parser relases to Central maven
repository
--------------------------------------+-------------------------------------
 Reporter:  bergun                    |       Owner:  bergun       
     Type:  enhancement               |      Status:  new          
 Priority:  medium                    |   Milestone:  PostGIS 2.1.2
Component:  java                      |     Version:  2.1.x        
 Keywords:  Central maven repository  |  
--------------------------------------+-------------------------------------

Comment(by 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

-- 
Ticket URL: <http://trac.osgeo.org/postgis/ticket/2626#comment:7>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.


More information about the postgis-tickets mailing list