Request for Maven Central publish

[bjornharrtell]

I would love to see future versions published to Maven Central under the org.locationtech namespace.

[fosskers]

This might resolve some dependency resolution issues I've had in the past when depending on JTS.

[dr-jts]

We can't publish 1.14 under org.locationtech, since that version was not a LT project.

Not sure about publishing future versions to Maven Central - needs a bit of research to see whether this is possible using the LT infrastructure.

[dsmiley]

LocationTech doesn't facilitate Maven Central publishing in any way. See my notes for doing this in Spatial4j: https://github.com/locationtech/spatial4j/blob/master/devnotes.md I can help if needed.

[bjornharrtell]

Not publishing 1.14 is understandable. Changed issue description to wish for future release only.

[fosskers]

We (the GeoTrellis project, also under LT) publish to Maven: https://search.maven.org/#artifactdetails%7Corg.locationtech.geotrellis%7Cgeotrellis-spark_2.11%7C1.0.0%7Cjar

But as far as I know we had to handle that ourselves.

[fosskers]

I just saw a related thread on the mailing list. Is there a ballpark estimate of when 1.15 might be released?

[jnh5y]

@fosskers At the minute, there is no estimate of when 1.15 will be released.

@dsmiley I'm going to try and sort out publishing JTS to Maven Central.

[jnh5y]

As an update / note, someone has published a JTS version 1.14.0 on Maven Central. Once we get through Eclipse's incubation process, we'll update the documentation with information about a JTS version 1.15 release.

[mprins]

regarding 1.14.0 there is something fishy, the tag in the source repo is dated 2016-01-12 (https://sourceforge.net/p/jts-topo-suite/code/1121/) and the artifacts have been published on 23-Sep-2015 (https://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.vividsolutions%22)

ideally a relocation pom should be published as well eg as 1.14.1 to notify any tooling of the change in groupId, see: https://maven.apache.org/guides/mini/guide-relocation.html (actually it should have been done between 1.13 and 1.14 as well because the artifacts were split up, but I guess that is too late now)

[bjornharrtell]

I do remember @dr-jts mentioning at that time that the stable release was done ~september 2015 but that he didn't get around to tag and write the changelog until later (i.e start of 2016). So AFAIK the Maven artifact is code-identical to the stable one.

[mprins]

ok, that would explain things

[IzakMarais]

There is reference in https://github.com/locationtech/jts/blob/master/USING.md of how to use jts with new and old versions of maven. It uses a different hosted repository (not maven central).

Added this for reference (in case others are also unaware of the existing maven solution).

[jnh5y]

JTS 1.14.0 is available on Maven Central.

This issue is valid until JTS releases via Eclipse's process and publishes jars under org.locationtech.jts on Maven Central. I'm queued up to do that as soon as we knocked out the last of the Eclipse review process.

[karussell]

When searching the maven repo, it clearly indicates jts 1.15.0 should be available now too, but the release is somehow empty - is this intended?

[karussell]

Ah, I was wrong: it is jts-core ... see the release notice.

[dr-jts]

It's a bit confusing. JTS is structured as a set of modules. jts-core and jts-io are the most relevant ones for developers. They are available in Maven Central:

http://repo1.maven.org/maven2/org/locationtech/jts/jts-core/1.15.0/
http://repo1.maven.org/maven2/org/locationtech/jts/io/jts-io-common/1.15.0/

Ideas on how to better structure this are welcome.

[karussell]

All fine, maybe a pointer in the readme to migration would help a bit but other than this the migration was easy 👍

IMO this issue can be closed?

[dr-jts]

Good idea, and done.

[snodnipper]

@dr-jts regarding structure it might be worth considering the policies used by others for group / artifact naming. I hadn't noticed the jts-io-common artifact because it was under a different group ID.

Furthermore, it would be good to include the maven coordinates in the readme...similar way to, say, retrofit.

Happy to raise a separate issue as necessary.

[jnh5y]

@snodnipper did you see https://github.com/locationtech/jts/blob/master/USING.md ?

From that document, do you have a concrete recommendation for a change in package names?

[snodnipper]

Hi @jnh5y, thanks for pointing out USING.md. If we used the recommendations from the likes of Jake / Square we might have:

1. Main JTS library (currently core)
   Group ID: org.locationtech.jts
   Artifact: jts
   Version: 1.15.0
   The current jts artifact might change to org.locationtech.jts:parent:1.15.0, similar to the retrofit2 parent.

2. The existing JTS IO Common module might have coordinates:
   Group ID: org.locationtech.jts
   Artifact: io
   Version: 1.15.0

3. If, say, the SDE module was published then that might have coordinates:
   Group ID: org.locationtech.jts
   Artifact: io-sde
   Version: 1.15.0

From a developer perspective, they would search maven central for "org.locationtech.jts". They would then see all of the JTS modules available as a list and add them as necessary.
For example:
compile 'org.locationtech.jts:jts:1.15.0'
compile 'org.locationtech.jts:io:1.15.0'
compile 'org.locationtech.jts:io-sde:1.15.0'

A future JTS 2 release might have a group id and package namespace org.locationtech.jts2.

A screenshot of what this looks like for Retrofit 2 on search.maven.org is shown below. You will note the retrofit-adatpers, retrofit-converters and retrofit-mock references, which have corresponding modules. This might be relevant to, say, the JTS IO module structure.

Note: I used the 1.15.0 version reference only for illustrative purposes.

[andyjefferson]

Just a further request for a complete "LocationTech" JTS release on Maven in a similar vein to the "Vividsolutions" JTS releases. For example with (vividsolutions) 1.14.0 I have deps on

        <dependency>
            <groupId>com.vividsolutions</groupId>
            <artifactId>jts-core</artifactId>
            <version>1.14.0</version>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>com.vividsolutions</groupId>
            <artifactId>jts-io</artifactId>
            <version>1.14.0</version>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>com.vividsolutions</groupId>
            <artifactId>jts-ora</artifactId>
            <version>1.14.0</version>
            <optional>true</optional>
        </dependency>

Yes I read USING.md ... whilst there exists jts-core 1.16.0-RC1 (jar), there is no jar for "jts-io", and nothing at all for "jts-ora" (yes, I read that it depends on other libs, but is that really a reason not to provide it? the point of Maven builds is to make integration simpler). When it is possible to do this with a release then I can change DataNucleus-geospatial layer over to this library.

[jnh5y]

@andyjefferson As a note, I think the jts-io 1.14.0 jar is now the jts-io-core 1.15+ jar.

The jts-ora jar isn't part of the default build. We've hesitated to ship it since it requires a non-open source dependency to build and it seems that registration is required to download the Oracle jar...

[andyjefferson]

@jnh5y Yes I saw the (artifactId) rename of the "jts-io" ... to "jts-io-common" I think (changing its groupId as well in the process ... why do that?).

As far as releasing something that depends on a non-open source dep, sure it's inconvenient, but then Oracle is never convenient. Many projects have software that depend on that Oracle JDBC driver (including one of mine, datanucleus-rdbms). But the only person who has to go to their silly site, register as Mickey Mouse, download it and manually install it in their local Maven repo is the person doing the release. The subsequent released jar is not tinged in any way, and it then makes that functionality usable for those people it was written for, so people benefit from these extra features :-)

[andyjefferson]

Closed as in "we don't want to do this"?
Closed as in "we have no resource"?
Closed as in "this is covered by a different issue"?
An insight would be useful as to whether this project will ever publish the addon modules on Maven.
Thanks

[jnh5y]

@andyjefferson When Björn opened this issue, the JTS developers hadn't published anything on Maven Central recently. Since we've succeeded in getting the core up on Maven Central, this issue has been closed.

Publishing artifacts for the ESRi and Oracle integrations may be worth a separate issue. Given that there are non-open source dependencies, we have some restrictions from the Eclipse Foundation to consider.

That said, we generally do want to be helpful. If you start an issue and there's lots of feedback on it, it'll make it easier for us to prioritize it. This project is maintained mainly by volunteer effort and publishing those add-ons is definitely something that'd require additional work on our part.