+1 to deprecate managed resources in lieu of easier to maintain (and more
flexible) file based GET/PUT into the configset.

> I don't know if 9 is too soon from a deprecation stand point

IMO it's never too soon as long as there is a deprecated release.  Users
take their time upgrading to major versions.

> How much harder are the use-cases currently covered by managed resources,
if that module was removed?

I believe in practice, users synchronize one-way from their DB to Solr if
they have dynamic resources like this.  This is true where I work.
Otherwise, they would probably be using Solr as the source of truth, which
doesn't seem architecturally-sound for most apps IMO.  Those users
(hopefully few) would have to spend some time re-engineering the approach.
Given one-way sync, the transition here is pretty easy:  serialize the
client-managed data to the right Solr format (stopwords vs synonyms vs ...)
and then a file upload to Solr/ZK and then telling Solr which collections
to "reload".

Hmmm; seems the configSet API doesn't have an API to update a single file!
I wonder if uploading a configSet to the same name effectively overwrites
newly updated files but does not delete the existing files?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Sep 23, 2020 at 10:28 AM Timothy Potter <thelabd...@gmail.com>
wrote:

> I agree we should deprecate the managed resources feature, it was the
> first thing I was asked to build by LW nearly 7 years ago, before I was a
> committer. Restlet was already in place and I built on top of that, not
> sure who introduced it originally (nor do I care). Clearly from the vantage
> point of looking back, JAX-RS and Jersey won the day with REST in Java but
> that simply wasn't the case back then. What's important is how we move
> forward vs. bestowing judgement backed by wisdom of hindsight on decisions
> made many years ago.
>
> In the short term, does Apache have an Artifactory (or similar) where we
> can host the Restlet dependencies for Github to pull them from? If not,
> then we can port the code that's using Restlet over to using JAX-RS /
> Jersey. Personally I'd prefer we remove Managed Resources support from 9
> instead of porting the Restlet code but I don't know if 9 is too soon from
> a deprecation stand point?
>
> Tim
>
>
> On Mon, Sep 21, 2020 at 11:33 PM Noble Paul <noble.p...@gmail.com> wrote:
>
>> We should deprecate that feature and remove restlet dependency altogether
>>
>> On Mon, Sep 21, 2020 at 10:20 PM Joel Bernstein <joels...@gmail.com>
>> wrote:
>> >
>> > Restlet again!!!!!!!
>> >
>> >
>> >
>> > Joel Bernstein
>> > http://joelsolr.blogspot.com/
>> >
>> >
>> > On Mon, Sep 21, 2020 at 7:18 AM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>> >>
>> >> Do we have a community blessed alternative to restlet already?
>> >>
>> >> On Sep 20, 2020, at 9:40 AM, Noble Paul <noble.p...@gmail.com> wrote:
>> >>
>> >> Haha.
>> >>
>> >> In fact schema APIs don't use restlet. Only the managed resources use
>> it
>> >>
>> >> On Sat, Sep 19, 2020, 3:35 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >>>
>> >>> If I were talend, I'd immediately start publishing to maven central.
>> If I were the developer who built the schema APIs, I would never have used
>> restlet to begin with.
>> >>>
>> >>> On Sat, 19 Sep, 2020, 1:13 am Uwe Schindler, <u...@thetaphi.de> wrote:
>> >>>>
>> >>>> I was thinking the same. Because GitHub does not cache the
>> downloaded artifacts like our jenkins servers.
>> >>>>
>> >>>> It seems to run it in a new VM or container every time, so it
>> downloads all artifacts. If I were Talend, I'd also block this.
>> >>>>
>> >>>> Uwe
>> >>>>
>> >>>> Am September 18, 2020 7:32:47 PM UTC schrieb Dawid Weiss <
>> dawid.we...@gmail.com>:
>> >>>>>
>> >>>>> I don't think it's http/https - I believe restlet repository simply
>> >>>>> bans github servers because of excessive traffic? These URLs work
>> for
>> >>>>> me locally...
>> >>>>>
>> >>>>> Dawid
>> >>>>>
>> >>>>> On Fri, Sep 18, 2020 at 6:35 PM Christine Poerschke (BLOOMBERG/
>> >>>>> LONDON) <cpoersc...@bloomberg.net> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>  This sounds vaguely familiar. "http works, https does not work"
>> and https://issues.apache.org/jira/browse/SOLR-13756 possibly related?
>> >>>>>>
>> >>>>>>  From: dev@lucene.apache.org At: 09/18/20 10:01:29
>> >>>>>>  To: dev@lucene.apache.org
>> >>>>>>  Subject: Re: restlet dependencies
>> >>>>>>
>> >>>>>>  I don't think it is, sadly.
>> >>>>>>  https://repo1.maven.org/maven2/org/restlet
>> >>>>>>
>> >>>>>>  The link you provided (mvnrepository) aggregates from several
>> maven
>> >>>>>>  repositories.
>> >>>>>>
>> >>>>>>
>> >>>>>>  D.
>> >>>>>>
>> >>>>>>  On Fri, Sep 18, 2020 at 10:46 AM Ishan Chattopadhyaya
>> >>>>>>  <ichattopadhy...@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>  Sorry, afk, but I heard (*hearsay*) that restlet is also on
>> maven central
>> >>>>>>
>> >>>>>> these days. Can we confirm and switch to that? Sorry, if that's
>> not the case.
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>  On Fri, 18 Sep, 2020, 1:15 pm Dawid Weiss, <
>> dawid.we...@gmail.com> wrote:
>> >>>>>>>>
>> >>>>>>>>
>> >>>>>>>>  Just FYI: can't get PR builds on github to work recently
>> because of this:
>> >>>>>>>>
>> >>>>>>>>> Could not resolve all files for configuration
>> >>>>>>
>> >>>>>> ':solr:core:compileClasspath'.
>> >>>>>>>>
>> >>>>>>>>  350 > Could not download org.restlet.ext.servlet-2.4.3.jar
>> >>>>>>>>  (org.restlet.jee:org.restlet.ext.servlet:2.4.3)
>> >>>>>>>>  351 > Could not get resource
>> >>>>>>>>
>> >>>>>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>>  352 > Could not GET
>> >>>>>>>>
>> >>>>>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet.ext.servlet/2.4.3/org.res
>> >>>>>> tlet.ext.servlet-2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>>  353 > Connection reset
>> >>>>>>>>  354 > Could not download org.restlet-2.4.3.jar
>> >>>>>>>>  (org.restlet.jee:org.restlet:2.4.3)
>> >>>>>>>>  355 > Could not get resource
>> >>>>>>>>
>> >>>>>> '
>> https://maven.restlet.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-2.4.3.j
>> >>>>>> ar'.
>> >>>>>>>>
>> >>>>>>>>  356 > Could not GET
>> >>>>>>>>
>> >>>>>> '
>> https://maven.restlet.talend.com/org/restlet/jee/org.restlet/2.4.3/org.restlet-
>> >>>>>> 2.4.3.jar'.
>> >>>>>>>>
>> >>>>>>>>  357 > Connection reset
>> >>>>>>>>
>> >>>>>>>>  D.
>> >>>>>>>> ________________________________
>> >>>>>>>>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >>>>>>>>  For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>>>>>>>
>> >>>>>> ________________________________
>> >>>>>>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >>>>>>  For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>>>>>
>> >>>>>>
>> >>>>> ________________________________
>> >>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>>>>
>> >>>>
>> >>>> --
>> >>>> Uwe Schindler
>> >>>> Achterdiek 19, 28357 Bremen
>> >>>> https://www.thetaphi.de
>> >>
>> >>
>> >> _______________________
>> >> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>> | http://www.opensourceconnections.com | My Free/Busy
>> >> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> >> This e-mail and all contents, including attachments, is considered to
>> be Company Confidential unless explicitly stated otherwise, regardless of
>> whether attachments are marked as such.
>> >>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Reply via email to