[ 
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]

Reply via email to