postgis / postgis-java

java bindings for postgis
147 stars 56 forks source link

pom / repositories causing problems for jts driver #52

Closed TimPigden closed 6 years ago

TimPigden commented 7 years ago

Hi, Latest version of jts driver on maven is 2.2.1 This references a postgis-jdbc version 2.1.0 in the pom file. But 2.1.0 doesn't exist because it's an org.postigs not net.postgis So sbt (don't know about others) is failing because it's looking for transitive dependency to net.postgis v 2.1.0 instead of org.postgis 2.1.0

phillipross commented 7 years ago

To be clear, the "org.postgis" group id is no longer used and all artifacts as of version 2.0 are rooted at the "net.postgis" group id. Both postgis-jdbc and postgis-jdbc-jtsparser artifacts exist with net.postgis as of version 2.2.1

The pom files can be viewed here: postgis-jdbc v2.2.1 postgis-jdbc-jtsparser v2.2.1

The postgis-jdbc-jtsparser artifact has no dependency on postgist-jdbc artifact. Are you certain that you're specifying the maven coordinates correctly?

TimPigden commented 7 years ago

Hi, Thanks for getting back so I'm using sbt I have the single relevant link in my sbt file

val postgis = "net.postgis" % "postgis-jdbc-jtsparser" % "2.2.1"

I'm using sonatype repository which is the default https://oss.sonatype.org/content/repositories/releases/net/postgis/postgis-jdbc-jtsparser/2.2.1/postgis-jdbc-jtsparser-2.2.1.pom

That's the same pom as you've just linked to me

If you look at it, then the postgis-jdbc link in the pom has:

net.postgis postgis-jdbc [2.1.0,)

This makes sbt go look for net.postgis release 2.1.0 But as far as I can see, net.postgis doesn't (and probably never did) exist at 2.1.0 - the earliest reference is 2.1.7.2. So I think the version referenced in the pom file should be [2.2.0,) or [2.1.7.2, ) or whatever. But I'm no export in these things. All I can say is that my sbt reference makes sbt go look for a non-existent net.postgis at 2.1.0

By contrast 2.1.7.2 jts goes to look for jdbc 2.1.7.2 as a dependency which does exist and does owrk.

On 19 June 2017 at 22:23, Phillip Ross notifications@github.com wrote:

To be clear, the "org.postgis" group id is no longer used and all artifacts as of version 2.0 are rooted at the "net.postgis" group id. Both postgis-jdbc and postgis-jdbc-jtsparser artifacts exist with net.postgis as of version 2.2.1

The pom files can be viewed here: postgis-jdbc v2.2.1 https://repo1.maven.org/maven2/net/postgis/postgis-jdbc/2.2.1/postgis-jdbc-2.2.1.pom postgis-jdbc-jtsparser v2.2.1 https://repo1.maven.org/maven2/net/postgis/postgis-jdbc-jtsparser/2.2.1/postgis-jdbc-jtsparser-2.2.1.pom

The postgis-jdbc-jtsparser artifact has no dependency on postgist-jdbc artifact. Are you certain that you're specifying the maven coordinates correctly?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/postgis/postgis-java/issues/52#issuecomment-309577775, or mute the thread https://github.com/notifications/unsubscribe-auth/ABNjpynNVdvfb_IBJ5hxAVXeWg_I1ZR0ks5sFubUgaJpZM4N-V51 .

-- Tim Pigden Optrak Distribution Software Limited +44 (0)1992 517100 http://www.linkedin.com/in/timpigden http://optrak.com Optrak Distribution Software Ltd is a limited company registered in England and Wales. Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

phillipross commented 7 years ago

It appears that possibly sbt doesn't handle the version ranges. <version>[2.1.0,)</version> should match versions greater than or equal to 2.1.0, but maybe sbt has a different way of interpreting the versions.

Thanks for bringing this to light. It might be more proper to drop the use of version ranges and only garuntee dependency compatibility between exact versions of individual artifacts.

As a meantime workaround, maybe you can declare both dependencies in sbt with the specific versions instead of relying on the resolution of transitive dependencies?

TimPigden commented 7 years ago

Hi I'll raise it over on sbt as well, so I get an understanding of what it actually does.

On 20 June 2017 at 02:13, Phillip Ross notifications@github.com wrote:

It appears that possibly sbt doesn't handle the version ranges.

[2.1.0,) should match versions greater than or equal to 2.1.0, but maybe sbt has a different way of interpreting the versions. Thanks for bringing this to light. It might be more proper to drop the use of version ranges and only garuntee dependency compatibility between exact versions of individual artifacts. As a meantime workaround, maybe you can declare both dependencies in sbt with the specific versions instead of relying on the resolution of transitive dependencies? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub , or mute the thread .

-- Tim Pigden Optrak Distribution Software Limited +44 (0)1992 517100 http://www.linkedin.com/in/timpigden http://optrak.com Optrak Distribution Software Ltd is a limited company registered in England and Wales. Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings, Hoe Lane, Ware, SG12 9LR England This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Optrak Distribution Software Ltd. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

phillipross commented 7 years ago

This sounds good. It would be interesting to know.

I've also filed issue https://github.com/postgis/postgis-java/issues/53 with the intention to switch from using version ranges to using explicit versions.

TimPigden commented 7 years ago

workaround for sbt users val postgisJts = "net.postgis" % "postgis-jdbc-jtsparser" % "2.2.1" exclude("net.postgis", "postgis-jdbc") val postgis = "net.postgis" % "postgis-jdbc" % "2.2.1" You can add the eclude as long as you include the stuff it actually depends upon explicitly then it won't go looking for the range check

phillipross commented 6 years ago

resolved with pull request #58