-
Notifications
You must be signed in to change notification settings - Fork 881
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JAVA-2982: Follow-up to recent PR making ESRI an optional dependency #1580
Changes from all commits
9e43d52
130489c
4c7e838
5e9ce0d
953c72f
07293da
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -146,9 +146,6 @@ | |
--> | ||
<include>com.datastax.oss:java-driver-core</include> | ||
<include>io.netty:*</include> | ||
<include>com.esri.geometry:*</include> | ||
<include>org.json:*</include> | ||
<include>org.codehaus.jackson:*</include> | ||
<include>com.fasterxml.jackson.core:*</include> | ||
</includes> | ||
</artifactSet> | ||
|
@@ -161,18 +158,6 @@ | |
<pattern>io.netty</pattern> | ||
<shadedPattern>com.datastax.oss.driver.shaded.netty</shadedPattern> | ||
</relocation> | ||
<relocation> | ||
<pattern>com.esri</pattern> | ||
<shadedPattern>com.datastax.oss.driver.shaded.esri</shadedPattern> | ||
</relocation> | ||
<relocation> | ||
<pattern>org.json</pattern> | ||
<shadedPattern>com.datastax.oss.driver.shaded.json</shadedPattern> | ||
</relocation> | ||
<relocation> | ||
<pattern>org.codehaus.jackson</pattern> | ||
<shadedPattern>com.datastax.oss.driver.shaded.codehaus.jackson</shadedPattern> | ||
</relocation> | ||
<relocation> | ||
<pattern>com.fasterxml.jackson</pattern> | ||
<shadedPattern>com.datastax.oss.driver.shaded.fasterxml.jackson</shadedPattern> | ||
|
@@ -194,24 +179,6 @@ | |
<exclude>META-INF/**</exclude> | ||
</excludes> | ||
</filter> | ||
<filter> | ||
<artifact>com.esri.geometry:*</artifact> | ||
<excludes> | ||
<exclude>META-INF/**</exclude> | ||
</excludes> | ||
</filter> | ||
<filter> | ||
<artifact>org.json:*</artifact> | ||
<excludes> | ||
<exclude>META-INF/**</exclude> | ||
</excludes> | ||
</filter> | ||
<filter> | ||
<artifact>org.codehaus.jackson:*</artifact> | ||
<excludes> | ||
<exclude>META-INF/**</exclude> | ||
</excludes> | ||
</filter> | ||
<filter> | ||
<artifact>com.fasterxml.jackson.core:*</artifact> | ||
<excludes> | ||
|
@@ -311,6 +278,11 @@ | |
<artifactId>jctools-core</artifactId> | ||
<version>2.1.2</version> | ||
</additionalDependency> | ||
<additionalDependency> | ||
<groupId>com.esri.geometry</groupId> | ||
<artifactId>esri-geometry-api</artifactId> | ||
<version>1.2.1</version> | ||
</additionalDependency> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. javadoc generation was throwing warnings about missing classes without this declaration in place |
||
</additionalDependencies> | ||
</configuration> | ||
</execution> | ||
|
@@ -340,7 +312,7 @@ | |
<!-- | ||
1) Don't import packages shaded in the driver bundle. Note that shaded-guava lives | ||
in its own bundle, so we must explicitly *not* mention it here. | ||
-->!com.datastax.oss.driver.shaded.netty.*, !com.datastax.oss.driver.shaded.esri.*, !com.datastax.oss.driver.shaded.json.*, !com.datastax.oss.driver.shaded.codehaus.jackson.*, !com.datastax.oss.driver.shaded.fasterxml.jackson.*, | ||
-->!com.datastax.oss.driver.shaded.netty.*, !com.datastax.oss.driver.shaded.fasterxml.jackson.*, | ||
<!-- | ||
2) Don't include the packages below because they contain annotations only and are | ||
not required at runtime. | ||
|
@@ -366,7 +338,7 @@ | |
1) The driver's packages (API and internal); | ||
2) All shaded packages, except Guava which resides in a separate bundle. | ||
--> | ||
<Export-Package>com.datastax.oss.driver.api.core.*, com.datastax.oss.driver.internal.core.*, com.datastax.dse.driver.api.core.*, com.datastax.dse.driver.internal.core.*, com.datastax.oss.driver.shaded.netty.*, com.datastax.oss.driver.shaded.esri.*, com.datastax.oss.driver.shaded.json.*, com.datastax.oss.driver.shaded.codehaus.jackson.*, com.datastax.oss.driver.shaded.fasterxml.jackson.*,</Export-Package> | ||
<Export-Package>com.datastax.oss.driver.api.core.*, com.datastax.oss.driver.internal.core.*, com.datastax.dse.driver.api.core.*, com.datastax.dse.driver.internal.core.*, com.datastax.oss.driver.shaded.netty.*, com.datastax.oss.driver.shaded.fasterxml.jackson.*,</Export-Package> | ||
</instructions> | ||
<rebuildBundle>true</rebuildBundle> | ||
</configuration> | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -479,8 +479,9 @@ don't use any of the above features, you can safely exclude the dependency: | |
Our [geospatial types](../dse/geotypes/) implementation is based on the [Esri Geometry | ||
API](https://github.com/Esri/geometry-api-java). | ||
|
||
Esri is declared as a required dependency, but the driver can operate normally without it. If you | ||
don't use geospatial types anywhere in your application, you can exclude the dependency: | ||
For driver versions >= 4.4.0 and < 4.14.0 Esri is declared as a required dependency, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The TinkerPop example explicitly referred to an inclusive range, but in this case I wanted the range to be inclusive on the low end but exclusive on the high end (in order to explicitly convey the idea that all drivers before the named version used a different behaviour). Since this changed the semantics slightly I thought that perhaps identifying versions via the >= and < syntax might be more explicit. I'm open to other ideas of presenting this information if this isn't clear. |
||
although the driver can operate normally without it. If you don't use geospatial types | ||
anywhere in your application you can exclude the dependency: | ||
|
||
```xml | ||
<dependency> | ||
|
@@ -496,6 +497,22 @@ don't use geospatial types anywhere in your application, you can exclude the dep | |
</dependency> | ||
``` | ||
|
||
Starting with driver 4.14.0 Esri has been changed to an optional dependency. You no longer have to | ||
adutra marked this conversation as resolved.
Show resolved
Hide resolved
|
||
explicitly exclude the dependency if it's not used, but if you do wish to make use of the Esri | ||
library you must now explicitly specify it as a dependency : | ||
|
||
```xml | ||
<dependency> | ||
<groupId>com.esri.geometry</groupId> | ||
<artifactId>esri-geometry-api</artifactId> | ||
<version>${esri.version}</version> | ||
adutra marked this conversation as resolved.
Show resolved
Hide resolved
|
||
</dependency> | ||
``` | ||
|
||
In the dependency specification above you should use any 1.2.x version of Esri (we recommend | ||
1.2.1). These versions are older than the current 2.x versions of the library but they are | ||
guaranteed to be fully compatible with DSE. | ||
|
||
#### TinkerPop | ||
|
||
[Apache TinkerPop™](http://tinkerpop.apache.org/) is used in our [graph API](../dse/graph/), | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -9,6 +9,26 @@ request cannot be executed because all nodes tried were busy. Previously you wou | |
`NoNodeAvailableException` but you will now get back an `AllNodesFailedException` where the | ||
`getAllErrors` map contains a `NodeUnavailableException` for that node. | ||
|
||
#### Esri Geometry dependency now optional | ||
adutra marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Previous versions of the Java driver defined a mandatory dependency on the Esri geometry library. | ||
This library offered support for primitive geometric types supported by DSE. As of driver 4.14.0 | ||
this dependency is now optional. | ||
|
||
If you do not use DSE (or if you do but do not use the support for geometric types within DSE) you | ||
should experience no disruption. If you are using geometric types with DSE you'll now need to | ||
explicitly declare a dependency on the Esri library: | ||
|
||
```xml | ||
<dependency> | ||
<groupId>com.esri.geometry</groupId> | ||
<artifactId>esri-geometry-api</artifactId> | ||
<version>${esri.version}</version> | ||
</dependency> | ||
``` | ||
|
||
See the [integration](../manual/core/integration/#esri) section in the manual for more details. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Very much based on the example used when TinkerPop was made optional. I've explicitly added this in the 4.14.0 section under the assumption that changing a dependency from required to optional breaks backwards compat and thus requires at least a minor release. |
||
### 4.13.0 | ||
|
||
#### Enhanced support for GraalVM native images | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit hesitant about this. Making a dependency optional and shading it are different concerns.
Initially, the decision to shade a dependency was taken by looking at the likelihood of a version conflict for a given dependency. For Esri, we deemed it high because the driver requires a very old Esri version.
I think we should keep shading Esri even if it is optional, wdyt? This means that in the shaded jar Esri would be present and shaded, just like it is now. I can't see a situation where this could be a problem for the end user.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see your point here... I'm just not sure I agree.
To be clear, the case you're describing is fairly precise. It would have to be something like the following:
This user will (possibly, even likely) experience a class conflict. But the cost for supporting this (quite limited case) is that every user of the shaded JAR has a larger JAR on their classpath. Initially it seemed like optimizing for the broad case made sense rather than doing so for the extremely precise case but I'm certainly open to argument.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well the shaded jar already has all of Netty in it, so adding Esri on top of it won't really make a noticeable size difference :-)
But OK, I don't mind if we stop shading Esri.