[
https://issues.apache.org/jira/browse/SOLR-16078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17597416#comment-17597416
]
Houston Putman commented on SOLR-16078:
---------------------------------------
[~dsmiley] this is more organizational than anything else, so that we have a
clean approach to how SolrJ is laid out. Having everything under /solr is a bit
messy in my opinion.
We would immediately backport this to 9.x after merging the main, since there
are few back-compat issues. No code is being changed here, the only changes are:
* Where do the modules live? Under /solr or /solr/solrj?
* Either the SolrJ module continues to contain just the core SolrJ code, or it
is a catch-all for all SolrJ code (this is back-compat).
* The group of the maven artifacts will change (this is actually
back-incompat, but we are already back-incompat for the solrj-zookeeper stuff
so not that much more harm?). If we can merge this for the same release as
solrj-zookeeper is introduced (9.1) then I think we can make this change
without issue.
> New solrj-core module
> ---------------------
>
> Key: SOLR-16078
> URL: https://issues.apache.org/jira/browse/SOLR-16078
> Project: Solr
> Issue Type: Sub-task
> Components: SolrJ
> Reporter: Jan Høydahl
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We should introduce a solrj-core module that is as slim as possible wrt
> dependencies.
> A user will then add solrj-core as well as any other solj-xx modules needed
> for their use.
> By marking it {{\@lucene.experimental}} we can change the API of this
> solrj-core during 9.x as we move stuff into other modules.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]