[jira] [Comment Edited] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15139774#comment-15139774
]
Nicholas Knize edited comment on LUCENE-6997 at 2/9/16 9:16 PM:
Updated patch to refactor {{GeoPoint*}} classes from
{{org.apache.lucene.spatial}} to {{org.apache.lucene.spatial.geopoint}}
was (Author: nknize):
Updated patch to refactor {GeoPoint*} classes from {org.apache.lucene.spatial}
to {org.apache.lucene.spatial.geopoint}
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial
>Reporter: Nicholas Knize
>Assignee: Nicholas Knize
> Labels: blocker
> Fix For: 5.5, trunk
>
> Attachments: LUCENE-6997.patch, LUCENE-6997.patch, LUCENE-6997.patch
>
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121761#comment-15121761
]
Nicholas Knize edited comment on LUCENE-6997 at 1/28/16 3:52 PM:
-
bq. What's missing, in your opinion? And did you actually mean Spatial4j? FYI
JTS as of yesterday is licensed BSD.
Hey wonderful! I actually meant JTS. Last conversation I had with Martin he
wasn't confident in a friendly timeline for relicense. I think the larger
discussion re: dependencies is still relevant? Unless there's a blacklist
somewhere of licenses we will always reject.
bq. I think Maven "optional" dependencies are for uses cases where you need a
class only at compile time (mandatory), but consumer (runtime) may not need it,
Its likely I misunderstood this so this clarification will certainly help. I
thought Java's module system is changing in Java 9 such that it needs all
dependencies at runtime? That's the relevancy of Java 9 in the discussion.
was (Author: nknize):
bq. What's missing, in your opinion? And did you actually mean Spatial4j? FYI
JTS as of yesterday is licensed BSD.
Hey wonderful! I actually meant JTS. Last conversation I had with Martin he
wasn't confident in a friendly timeline for relicense. I think the larger
discussion re: dependencies is still relevant? Unless there's a blacklist
somewhere of licenses we will always reject.
bq. I think Maven "optional" dependencies are for uses cases where you need a
class only at compile time (mandatory), but consumer (runtime) may not need it,
Its likely I misunderstood this so this clarification will certainly help. I
thought Java's module system is changing in Java 9 such that it needs all
dependencies are needed at runtime? That's the relevancy of Java 9 in the
discussion.
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121761#comment-15121761
]
Nicholas Knize edited comment on LUCENE-6997 at 1/28/16 4:12 PM:
-
bq. What's missing, in your opinion? And did you actually mean Spatial4j? FYI
JTS as of yesterday is licensed BSD.
Hey wonderful! I actually meant JTS. Last conversation I had with Martin he
wasn't confident in a friendly timeline for relicense. I think the larger
discussion re: dependencies is still relevant? Unless there's a blacklist
somewhere of licenses we will always reject.
bq. I think Maven "optional" dependencies are for uses cases where you need a
class only at compile time (mandatory), but consumer (runtime) may not need it,
Its likely I misunderstood this so this clarification will certainly help. I
thought Java's module system is changing in Java 9 such that it needs all
dependencies at runtime (even if the dependencies are not used)? That's the
relevancy of Java 9 in the discussion.
was (Author: nknize):
bq. What's missing, in your opinion? And did you actually mean Spatial4j? FYI
JTS as of yesterday is licensed BSD.
Hey wonderful! I actually meant JTS. Last conversation I had with Martin he
wasn't confident in a friendly timeline for relicense. I think the larger
discussion re: dependencies is still relevant? Unless there's a blacklist
somewhere of licenses we will always reject.
bq. I think Maven "optional" dependencies are for uses cases where you need a
class only at compile time (mandatory), but consumer (runtime) may not need it,
Its likely I misunderstood this so this clarification will certainly help. I
thought Java's module system is changing in Java 9 such that it needs all
dependencies at runtime? That's the relevancy of Java 9 in the discussion.
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121593#comment-15121593
]
Uwe Schindler edited comment on LUCENE-6997 at 1/28/16 2:41 PM:
Optional dependencies in Maven have nothing to do with extends or like that. If
you have a class that extends another class, the other class must be in
classpath. There is no "optional" extends in Java.
I think Maven "optional" dependencies are for uses cases where you need a class
only at compile time (mandatory), but consumer (runtime) may not need it, e.g.
if you have something like a implementation class in your JAR file that is
needed to support some 3rd party thing. If it is clearly separated, one would
only need the optional dependency if he uses this implementation class in his
own code.
But java always needs all classes that are referred from one class through
super, interfaces, method signatures.
Simple said: An optional dependency is not needed fro user, if the public api
of your artifact does not expose any classes from this dependency through its
signatures. If you have a factory class that just returns an abstract class,
implemented by some code in your optional dependency, it is fine, if you have
proper exception handling in your factory.
was (Author: thetaphi):
Optional dependencies in Maven have nothing to do with extends or like that. If
you have a class that extends another class, the other class must be in
classpath. There is no "optional" extends in Java.
I think Maven "optional" dependencies are for uses cases where you need a class
only at compile time (mandatory), but consumer (runtime) may not need it, e.g.
if you have something like a implementation class in your JAR file that is
needed to support some 3rd party thing. If it is clearly separated, one would
only need the optional dependency if he uses this implementation class in his
own code.
But java always needs all classes that are referred from one class through
super, interfaces, method signatures.
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-6997) Graduate GeoUtils and postings based GeoPointField from sandbox...
[
https://issues.apache.org/jira/browse/LUCENE-6997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15121593#comment-15121593
]
Uwe Schindler edited comment on LUCENE-6997 at 1/28/16 2:43 PM:
Optional dependencies in Maven have nothing to do with extends or like that. If
you have a class that extends another class, the other class must be in
classpath. There is no "optional" extends in Java.
I think Maven "optional" dependencies are for uses cases where you need a class
only at compile time (mandatory), but consumer (runtime) may not need it, e.g.
if you have something like a implementation class in your JAR file that is
needed to support some 3rd party thing. If it is clearly separated, one would
only need the optional dependency if he uses this implementation class in his
own code.
But java always needs all classes that are referred from one class through
super, interfaces, method signatures.
Simple said: An optional dependency is not needed fro user, if the public api
of your artifact does not expose any classes from this dependency through its
signatures. If you have a factory class that just returns an abstract class,
implemented by some code in your optional dependency, it is fine, if you have
proper exception handling in your factory (e.g., optional dep not on classpath).
was (Author: thetaphi):
Optional dependencies in Maven have nothing to do with extends or like that. If
you have a class that extends another class, the other class must be in
classpath. There is no "optional" extends in Java.
I think Maven "optional" dependencies are for uses cases where you need a class
only at compile time (mandatory), but consumer (runtime) may not need it, e.g.
if you have something like a implementation class in your JAR file that is
needed to support some 3rd party thing. If it is clearly separated, one would
only need the optional dependency if he uses this implementation class in his
own code.
But java always needs all classes that are referred from one class through
super, interfaces, method signatures.
Simple said: An optional dependency is not needed fro user, if the public api
of your artifact does not expose any classes from this dependency through its
signatures. If you have a factory class that just returns an abstract class,
implemented by some code in your optional dependency, it is fine, if you have
proper exception handling in your factory.
> Graduate GeoUtils and postings based GeoPointField from sandbox...
> --
>
> Key: LUCENE-6997
> URL: https://issues.apache.org/jira/browse/LUCENE-6997
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Nicholas Knize
>
> {{GeoPointField}} is a lightweight dependency-free postings based geo field
> currently in sandbox. It has evolved into a very fast lightweight geo option
> that heavily leverages the optimized performance of the postings structure.
> It was originally intended to graduate to core but this does not seem
> appropriate given the variety of "built on postings" term encoding options
> (e.g., see LUCENE-6930).
> Additionally, the {{Geo*Utils}} classes are dependency free lightweight
> relational approximation utilities used by both {{GeoPointField}} and the BKD
> based {{LatLonField}} and can also be applied to benefit the lucene-spatial
> module.
> These classes have been evolving and baking for some time and are at a
> maturity level qualifying for promotion from sandbox. This will allow support
> for experimental encoding methods with (minimal) backwards compatibility -
> something sandbox does not allow.
> Since GeoPoint classes are dependency free, all GeoPointField and support and
> utility classes currently in sandbox would be promoted to the spatial3d
> package. (possibly a separate issue to rename spatial3d to spatialcore or
> spatiallite?) Such that for basic lightweight Geo support one would only need
> a handful of lucene jars. By simply adding the lucene-spatial module and its
> dependency jars users can obtain more advanced geospatial support (heatmap
> facets, full shape relations, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
