Skip to content

maven central

Jump to bottom Edit New page
Jody Garnett edited this page Apr 11, 2015 · 8 revisions

Description

I'm interested in publishing geotools artifacts to maven central. The maven central guidelines require all of the dependencies be already published to maven central, or you can publish a fork under your own groupId to avoid confusion.

From what I can tell, here are the dependencies that need further investigation:

  • com.vividsolutions:jts:1.13
    • Check to see if the jts artifact published on maven central is from Martin Davis
  • java3d:vecmath:1.3.2
    • Downgrade to vecmath 1.3.1 (this would avoid license issue mentioned on email list with 1.3.2)
    • Or migrate to a different matrix library
  • org.eclipse.emf:ecore:2.6.1
    • downgrade to org.eclipse.emf:org.eclipse.emf.ecore:2.6.0.v20100614-1136
    • Or can migrate to the latest version
  • org.eclipse.emf:common:2.6.0 - basically same issue as above
  • org.apache.xml:xml-commons-resolver:1.2
    • Q: There is a xml-resolver:xml-resolver:1.2 which seems equivalent
  • style="line-height: 1.4285715;">it.geosolutions.imageio-ext:imageio-ext-* - such as imageio-ext-streams, style="line-height: 1.4285715;">imageio-ext-geocore, style="line-height: 1.4285715;">imageio-ext-tiff
  • net.sourceforge.groboutils:groboutils-core:5 is used with test scope in gt-epsg-hsql in one class: CrsCreationDeadlockTest
    • Options could be to replace this with something equivalent
    • Or we could look at porting the classes into GeoTools (the original product is under the MIT license though)
    • Or we could upload just a pom.xml (saying where to download it from)
  • jgridshift:jgridshift:1.0
    • Seems to be dead, we could upload the jar unchanged as org.geotools.jgridshift
    • Or we could look at porting the classes into GeoTools
    • Or we could upload just a pom.xml (saying where to download it from)
    • Or downstream apps could exclude this and support fewer CRS's?
  • For the JAI dependencies the following poms exist, but the jars no longer exist on maven central (https://issues.sonatype.org/browse/MVNCENTRAL-341)\

    • javax.media:jai_codec:1.1.3

      • Older version available with different groupId / version: com.sun.media:jai_codec:1.1.2_01

    • javax.medai:jai_imageio:1.1 - available under a different groupId: com.sun.media:jai_imageio:1.1

    • The suggest workaround will be to go ahead and publish to maven central and expect downstream applications to add an additional repository that provides JAI

  • to be continued ...

Initially thought we would need to update our **ogc **and w3c artifacts. Reviewing the pom.xml shows they should be okay.

<groupId>org.geotools.ogc</groupId>
<artifactId>net.opengis.csw</artifactId>

So it appears all our artifacts are listed under org.geotools.* as required by maven central.

Not sure if the internals of each artifact need to match up (as an example the gt-opengis artifact contains interfaces from the GeoAPI project).

Research

As a little background the backup plan for any artifact that we cannot resolve automatically with the maven central repository is to publish a pom.xml for each unresolved artifact with instructions for downstream applications to get the artifact (basically the suggested workaround for JAI above). With that said, here is an initial attempt to minimize the number of artifacts that will need to resort to that as a backup plan. Additionally the app-schema packaging was out of date and was updated to pull from current resource locations. Here's the diff: https://github.com/geotools/geotools/compare/master...ngageoint:maven-central

Note that there the 'repositories' and 'pluginRepositories' tags remain unchanged in pom.xml but there is an additional pom.xml.mavencentral with these tags removed to comply with maven central rules. I think it should be the responsibility of deploy/release scripts to use the .mavencentral file for the published artifact, and I'm open to suggestions as to where this logic should go.

After this set of changes I was able to minimize the artifacts that were not already on maven-central, and this is the more formal list of every dependency not on maven central after the aforementioned changes.

I organized the list by grouping artifacts together by a suggested resolution.

Proposed Solution: Publish a pom on maven central with instructions to download jar. This is the catch-all for artifacts I didn't have a better solution for but welcome suggestions.

javax.media:jai_codec:jar:1.1.3
javax.media:jai_core:jar:1.1.3
javax.media:jai_imageio:jar:1.1
net.sourceforge.hatbox:hatbox:jar:1.0.b7 (used by org.opengeo.geodb oin gt-jdbc-h2)
org.xerial:spatialite-jdbc:jar:3.7.2-2.4 (used in gt-jdbc-spatialite)
jfree:eastwood:jar:1.1.1-20090908 (used by gt-charts)

Proposed Solution: GeoSolutions publish artifacts to maven central?

it.geosolutions.imageio-ext:imageio-ext:pom:1.1.10
it.geosolutions.imageio-ext:imageio-ext-arcgrid:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdal-bindings:jar:1.9.2
it.geosolutions.imageio-ext:imageio-ext-gdal-plugin:pom:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalarcbinarygrid:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdaldted:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalecw:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalecwjp2:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalehdr:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalenvihdr:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalerdasimg:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalframework:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalidrisi:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalkakadujp2:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalmrsid:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalmrsidjp2:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalnitf:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-gdalrpftoc:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-geocore:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-imagereadmt:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-kakadu:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-kakadujni:jar:5.2.6
it.geosolutions.imageio-ext:imageio-ext-library:pom:1.1.10
it.geosolutions.imageio-ext:imageio-ext-plugin:pom:1.1.10
it.geosolutions.imageio-ext:imageio-ext-png:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-streams:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-tiff:jar:1.1.10
it.geosolutions.imageio-ext:imageio-ext-utilities:jar:1.1.10

Proposed Solution: Boundless publish 'OpenGeo' artifacts to maven central?

org.opengeo:geodb:jar:0.7-RC2
org.opengeo:geodb-parent:pom:0.7-RC2

Proposed Solution: Eclipse publish these artifacts or update gt-swt to latest eclipse dependencies available on maven central (I tried the latest, and changes need to be made in gt-swt)?

org.eclipse:core.commands:jar:3.6.0.I20100512-1500
org.eclipse:core.runtime:jar:3.6.0.v20100505
org.eclipse:equinox.common:jar:3.6.0.v20100503
org.eclipse:jface:jar:3.6.1.M20100825-0800
org.eclipse:swt.gtk.linux.x86:jar:3.6.1.v3655c
org.eclipse:swt.win32.win32.x86_64:jar:3.6.1.v3655c
org.eclipse:ui.workbench:jar:3.6.1.M20100826-1330

Proposed Solution: Oracle publish artifacts? If thats not going to happen move these to the catch-all with JAI and others.

com.oracle:dummy_spatial:jar:8.1.8
com.oracle:ojdbc14:jar:10.2.0.3.0

Proposed Solution: Publish as org.geotools.jgridshift?

jgridshift:jgridshift:jar:1.0

Proposed Solution: Upgrade to latest version (0.9.2) which is available on maven central?

jsqlparser:jsqlparser:jar:0.3.14

Proposed Solution: Replace with something similar?

net.sourceforge.groboutils:groboutils-core:jar:5

Status

Voting has not started yet:

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

  1. Review dependencies and compare to maven central

  2. Collaborate on vecmath replacement or change dependency to version 1.3.1

    1. work started on replacement at foss4gna code sprint

  3. Refactor gt-opengis

    1. may or may not be needed

  4. Set up deploy

    1. CodeHaus? First choice but it is being discountined (it is an approved location and maven central will synchronize from there)
    2. LocationTech? Would need to ask ... and set up an arrangement between the two organizations.
    3. OSGeo? Would need to ask SAC for a Nexus or similar and set up an arrangement between the two organizations.

Documentation Changes

list the pages effected by this proposal

Add a custom footer
Add a custom sidebar
Clone this wiki locally