[
https://issues.apache.org/jira/browse/LUCENE-7853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031768#comment-16031768
]
Hoss Man commented on LUCENE-7853:
----------------------------------
bq. Precommit is complaining about references from GeoPoint etc.
documentation-lint is very explicit when it complains -- it doesn't complain
about _classes_ it complains about _documentation_ -- specifically broken links
in the documentation. If the link is manually created that's one problem. if
the link is generated automatically by javadoc then that's an indirect
indication of other problems (like referring to package protected classes in
public method sigs) but you have to actually *look* at the details of the
errors.
In this specfic case, all of the errors stem from the root problem i
specifically drew your attention to. the other broken links are all in
"class-use" pages, where all methods that refer to a class are listed. Whether
the GeoPoint _class_ has been modified in a very long time is irrelevant to the
question of why links on it's "class-use" page might be broken -- what matters
is if any methods that refer to GeoPoint have been added/removed/modified and
result in broken links.
Bottom line: we shouldn't just ignore documentation-lint errors because it
looks like it's refering to classes that haven't changed "in a very long time"
If you actually look at check the exact errors & html files it directs you to,
the root cause is usually very clear.
> Request to change visibility of classes in geo3d
> ------------------------------------------------
>
> Key: LUCENE-7853
> URL: https://issues.apache.org/jira/browse/LUCENE-7853
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/spatial3d
> Reporter: Ignacio Vera
> Assignee: Karl Wright
> Fix For: master (7.0), 6.7
>
> Attachments: LUCENE-7853.patch
>
>
> I am creating my own spatial context by wrapping the objects in lucene geo3d
> library and implement my own query which mixes the recursive and the
> serialized strategy to add precision to searches.
>
> I had the following issue specially with polygons: The factory for creating
> polygons is slow and when serializing shapes, I already know if I am dealing
> with convex or concave polygons (in my case they are always concave). So when
> de-serializing a polygon I do not want to go through the factory to decide
> the type of polygon to create.
>
> Wouldn't make sense to add the possibility to create a type of polygon
> directly? you cannot create the polygons directly as they are protected in
> the package. My suggestion request would be either to add methods in the
> polygon factory to create a type of polygons with no checking (e.g.
> makeConcavePolygon(…)) or change the visibility of the classes so that they
> can be instantiated directly.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
