> But since yours would also require a solr server module, you could make a server module without any code maybe and just rely on the new solrj module?
Hmm, interesting idea... I was aware of the push to split up SolrJ and thought about going that route, but I didn't want to give up the "Off The Classpath By Default" benefit that contribs get us, since aws-secret-provider has some transitive deps that most people probably won't have a use for. I hadn't thought of making an "empty" contrib to wrap the SolrJ component, but I guess it's worth a shot? Thanks guys! Jason On Fri, May 6, 2022 at 2:57 AM Jan Høydahl <[email protected]> wrote: > If this aws-secret-provider is always going to be used on the server side, > then a server module could provide solrj extensions (in separate java > package) as part of the module I suppose. > However, if your SolrJ extension is useful by user clients, it should be > one of those soon-to-be solrj jars without core-dependencies as Houston > says. > > Jan > > 6. mai 2022 kl. 02:37 skrev Houston Putman <[email protected]>: > > Hey Jason, > > Im without my laptop right now, so i cant link them, but there are a few > JIRA tickets to split out SolrJ into separate modules (different than the > solr server modules). So i feel that would be a good fit for your use case. > > But since yours would also require a solr server module, you could make a > server module without any code maybe and just rely on the new solrj module? > That way people could use it just like any other solr server module. > > - Hosuton > > On Fri, May 6, 2022 at 9:32 AM Shawn Heisey <[email protected]> wrote: > >> On 5/5/2022 1:51 PM, Jason Gerlowski wrote: >> > TL;DR Can contribs/modules only extend Solr "core" classes, or are >> > they a valid way to package extensions of SolrJ functionality as well? >> >> I am pretty sure solr-core depends on solr-solrj ... so if you're >> depending on solr-core, you will need solrj too, and it should be pulled >> in automatically by any dependency manager. I believe you're fine to >> work with solrj classes in contrib/module. >> >> Thanks, >> Shawn >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >
