Motivation:

User list confusion over the number of geotools repositories available during a web search

Contact:

Jody Garnett

Tracker:

http://jira.codehaus.org/browse/GEOT-PENDING

Tagline:

repo where art thou?

Children:

Description

We have published GeoTools, over the years, to any number of different repositories. And then moved on; usually because the repositories cannot handle the strain.

This has resulted in two very interesting things:

http://mvnrepository.com/search.html?query=geotools (comes up empty!)
http://www.google.com.au/search?q=geotools+AND+repository+AND+maven (has 14,6000 results the first of which is maven.geotools.fr/repository

How can we fix? Well if you do the same search for geoserver ....

http://mvnrepository.com/search.html?query=geoserver (has geoserver 1.7)

And I see someone has published jts:

http://repo1.maven.org/maven2/com/vividsolutions/jts/

Turns out for a brief time geoserver published to codehaus and codehaus mirrors to central and I think Michael Bedward may know something about how jts got published.

So we could do the same - for stable releases.

Reference:

http://docs.codehaus.org/display/HAUSMATES/Maven+Guide

Status

This proposal is stalled waiting for volunteers to sign up to the tasks section.

Voting has not started yet:

Andrea Aime
Ben Caradoc-Davies
Christian Mueller
Ian Turton
Justin Deoliveira
Jody Garnett (current OSGeo representative)
Michael Bedward
Simone Giannecchini

Tasks

This section is used to make sure your proposal is complete (did you remember documentation?) and has enough paid or volunteer time lined up to be a success

	no progress		done		impeded		lack mandate/funds/time		volunteer needed

Check that codehaus still mirrors to maven central
- It appears to: Maven Guide
Check for any dependencies that are not in central? (Apparently this is a condition of being published? Except we saw geoserver listed...)
- We may need to set up geotools library into different groups depending on if they can be published or not? See Split up unsupported modules. That would be sad and probably not worth it - it would amount to us changing the requirements needed in order to be a supported module.
Update the pom.xml to publish to codehaus
Update the instructions
Clean up or mirror old repositories
- Possibly set up our osgeo org repo as a mirror?
- Ask refractions to shut off the old repository?
  Or should we not care since it uses "gt2" prefix?

API Changes

BEFORE

trunk/pom.xml

  ...
  <distributionManagement>
    <repository>
      <uniqueVersion>false</uniqueVersion>
      <id>osgeo</id>
      <name>Open Source Geospatial Foundation - Maven 2 repo</name>
      <url>dav:http://download.osgeo.org/webdav/geotools/</url>
    </repository>
    <snapshotRepository>
        <id>opengeo</id>
        <uniqueVersion>false</uniqueVersion>
        <name>OpenGeo Maven Repository</name>
        <url>dav:http://repo.opengeo.org</url>
    </snapshotRepository>
  </distributionManagement>
  ...

AFTER

Change to codehaus for publication

<distributionManagement>
    <repository>
      <id>codehaus.org</id>
      <name>GeoTools Central Repository</name>
      <url>dav:https://dav.codehaus.org/repository/geotools/</url>
    </repository>
    <snapshotRepository>
      <id>codehaus.org</id>
      <name>GeoTools Central Development Repository</name>
      <url>dav:https://dav.codehaus.org/snapshots.repository/geotools/</url>
    </snapshotRepository>
    <site>
      <id>codehaus.org</id>
      <url>dav:https://dav.codehaus.org/geotools/</url>
    </site>
  </distributionManagement>

Documentation Changes

list the pages effected by this proposal