Comments (26)
@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.
from jts.
This might resolve some dependency resolution issues I've had in the past when depending on JTS.
from jts.
Good idea, and done.
from jts.
Hi @jnh5y, thanks for pointing out USING.md. If we used the recommendations from the likes of Jake / Square we might have:
-
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. -
The existing JTS IO Common module might have coordinates:
Group ID: org.locationtech.jts
Artifact: io
Version: 1.15.0 -
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.
from 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.
from jts.
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.
from jts.
Not publishing 1.14 is understandable. Changed issue description to wish for future release only.
from jts.
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.
from jts.
I just saw a related thread on the mailing list. Is there a ballpark estimate of when 1.15
might be released?
from jts.
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.
from jts.
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)
from jts.
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.
from jts.
ok, that would explain things
from jts.
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).
from jts.
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.
from jts.
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?
from jts.
Ah, I was wrong: it is jts-core
... see the release notice.
from 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.
from jts.
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?
from jts.
@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.
from jts.
@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?
from jts.
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.
from jts.
@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...
from jts.
@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 :-)
from jts.
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
from jts.
@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.
from jts.
Related Issues (20)
- "Unable to find a convex corner" in ConstrainedDelaunayTriangulator HOT 1
- IncrementalDelaunayTriangulator needs logic to handle frame
- Single-side offset provides triangular spikes near sharp turns HOT 1
- Negative buffer operation leaves some collinear points (regression from 1.19.0)
- Single-side buffering closes shape only sometimes HOT 2
- NullPointerException thrown by SimpleNoder when geometry covers but does not overlap HOT 1
- How to take distance transfrom to meters?UTM'unit is meters? HOT 1
- parseKMLCoordinatesAndAttributes can fail
- BufferInputLineSimplifier doesn't simplify end segments of rings
- CoordinateArraySequence.getCoordinate is hard to understand HOT 1
- AppSweep identifies Medium security vulnerability: HTTP URLs to opengis were found HOT 2
- PolygonTriangulator fails to find a convex corner on provided valid geometry HOT 4
- Trying to use GeoServer and it seems the error comes back to Coordinate.setM HOT 1
- ConstrainedDelaunayTriangulator causes an IllegalStateException: Unable to find a convex corner HOT 3
- Buffer with Flat endcap produces artifacts
- Calculating difference and intersection between two polygons is resulting in a polygon having incorrect shape HOT 1
- Expose GeometryOverlay `isOverlayNG` flag
- Non-closed polygon parsing caused unexpected Exception HOT 1
- Abnormal result with BufferOp.getResultGeometry() method
- Incorrect Voronoi diagram generated for 4 points HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from jts.