[ https://issues.apache.org/jira/browse/LUCENE-7314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318797#comment-15318797 ]
Nicholas Knize commented on LUCENE-7314: ---------------------------------------- Like the class naming discussion I'm fine w/ whatever agreement can be reached. :) Things always change. FWIW this was my experience early on: bq. I suspect new users would start with Lucene's core, expecting to find usable defaults there for common use cases When I first started looking at spatial I immediately looked in the spatial module for everything spatial and assumed (by the name) the core module contained foundation dependencies required by other modules. I've also spoke with quite a few spatial shops that have been interested in contributing but are very confused by the location of lucene's spatial classes (clearly something that needs to be fixed). Like many devs they assume package and module names are self explanatory and don't RTFM (or is it RTFJD?) until they're totally confused. Unfortunately, the spatial javadocs didn't help them. bq. ...we would have javadocs there that point you to the spatial/spatial-extras to do more expert things This approach has always been fine w/ me - again, javadocs. It certainly wasn't the agreed approach earlier when I proposed promoting the postings based GeoPointField (which has the same public API) to core way back when. Back then even basic spatial was considered a "special use-case" that belonged in a spatial module. It sounds like this view has partially changed? :) (at least for "good default" spatial capability) bq. It's clearly important we make Lucene easier to use for the common use cases and by hiding away LatLonPoint in the spatial module, here, we fail to do that. I totally agree but part of this comment scares me. Just for my own understanding how do modules "hide away" good functionality (especially if they're well named)? If this is true isn't it a disservice to organize good/advanced/{insert adjective} functionality in separate modules? +0 to move specifically to core. +1 to postpone moving until an agreement can be reached. > Graduate InetAddressPoint and LatLonPoint to core > ------------------------------------------------- > > Key: LUCENE-7314 > URL: https://issues.apache.org/jira/browse/LUCENE-7314 > Project: Lucene - Core > Issue Type: Improvement > Reporter: Adrien Grand > Assignee: Adrien Grand > Priority: Minor > > Maybe we should graduate these fields (and related queries) to core for > Lucene 6.1? -- 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