[
https://issues.apache.org/jira/browse/SOLR-14680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177774#comment-17177774
]
Jason Gerlowski commented on SOLR-14680:
----------------------------------------
The build error Uwe mentioned is fixed, but there's a precommit error from
these changes on branch_8x now too.
{code:java}
-documentation-lint:
[jtidy] Checking for broken html (such as invalid tags)...
[delete] Deleting directory
/Users/jasongerlowski/checkouts/alt-solr/lucene-solr/lucene/build/jtidy_tmp
[echo] Checking for broken links...
[exec]
[exec] Crawl/parse...
[exec]
[exec] Verify...
[echo] Checking for malformed docs...
[exec]
[exec]
/Users/jasongerlowski/checkouts/alt-solr/lucene-solr/solr/build/docs/solr-solrj/overview-summary.html
[exec] missing description: org.apache.solr.cluster.api
[exec]
[exec] Missing javadocs were found!
{code}
Are you compiling and running precommit before you merge to branch_8x
[~noble.paul]? I understand it takes extra time and it _seems_ like running
stuff on master should be enough. But in practice there's enough divergence
between these branches that it really does need run both places. (As the two
issues here make clear). And on a personal note I get frustrated when I can't
run precommit on my own changes because it's already broken upstream. Please
run precommit before merging!
> Provide simple interfaces to our concrete SolrCloud classes
> -----------------------------------------------------------
>
> Key: SOLR-14680
> URL: https://issues.apache.org/jira/browse/SOLR-14680
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Assignee: Noble Paul
> Priority: Minor
> Time Spent: 10.5h
> Remaining Estimate: 0h
>
> All our current implementations of SolrCloud such as
> # ClusterState
> # DocCollection
> # Slice
> # Replica
> etc are concrete classes. Providing alternate implementations or wrappers is
> extremely difficult.
> SOLR-14613 is attempting to create such interfaces to make their sdk simpler
> The objective is not to have a comprehensive set of methods in these
> interfaces. We will start out with a subset of required interfaces. We
> guarantee is that signatures of methods in these interfaces will not be
> deleted/changed . But we may add more methods as and when it suits us
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
