janhoy commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2039249157
Probably let features like this be driven by user demand. If no
user/committer requests aws-cred handled by SolrJ client side, let's not do it.
But if there is a need, then the module could b
HoustonPutman commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2034982016
Currently yes, but there's a PR for one that might be SolrJ compatible:
https://github.com/apache/solr/pull/1994. Just thinking about an eventual
possibility.
--
This is an automate
janhoy commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2034965063
I might be mis interpreting your statement. But as far as I know, all
`modules` are server-side only. The two you mentioned both depend on
`solr-core`.
--
This is an automated message fro
HoustonPutman commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2034768833
> @HoustonPutman Which other modules are you thinking about, except the
`solrj-*` ones?
@janhoy Sorry I missed this, I'm thinking about the ones that would be used
by SolrJ, lik
janhoy commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2033283234
I parked it here so we don't forget: SOLR-17223
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to
uschindler commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2031724690
Will you port the renderJavadocs from Lucene, I think it might be a good
idea.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to G
janhoy merged PR #2360:
URL: https://github.com/apache/solr/pull/2360
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
janhoy commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2011685238
I implemented your proposals @uschindler. I kept the definition of default
and solrj java versions in main `build.gradle` for better visibility (needed to
move it above the sourcing of `globa
HoustonPutman commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2010324248
This is great. There are some modules that don't rely on Solr Core, just
SolrJ, so they are consumable as a SolrJ plugin. We should make sure those
modules are built with the SolrJ jav
uschindler commented on PR #2360:
URL: https://github.com/apache/solr/pull/2360#issuecomment-2010214595
> Maybe we should assign a per-project `ext.javaVersion` in the general
settings file in the gradle root folder once and reuse it at all places where
`rootProject.minJavaVersion` was used
janhoy opened a new pull request, #2360:
URL: https://github.com/apache/solr/pull/2360
https://issues.apache.org/jira/browse/SOLR-17205
This PR only adds the plumbing, does not bump main
--
This is an automated message from the Apache Git Service.
To respond to the message, please l
11 matches
Mail list logo
