Jan, I think this is a great option. Angular's future is probably < 5 years. More and more people move to React and Vue every day it seems. Very occasionally, people move to StencilJS (which we should avoid like the plague). At least, thee insights are what the market and my friends tell me.
thanks, Marcus On Thu, Apr 23, 2020 at 1:06 AM Jan Høydahl <jan....@cominvent.com> wrote: > The old UI is not perfect, and it cannot do everything, i.e. you cannot > choose replica types when creating a collection, it has no support for > authoring Autoscaling rules, no support for doing backup/restore etc. The > dream would of course be that the new UI is so sweet to work with that > almost any new feature added to the backend also gets a simple UI > component, if not in the same release or by the same developer, then at > least a release or two further down the road. > > Why I put the three github links in this thread was not because it is a > thorough survey of everything that is out there. It was 30min search on > github just to find prior art. I expect whoever drives the SIP work to do > even more thorough investigation as to what our options are. Not being a > full-time frontend engineer, I cannot speak for Angular’s future. It would > of course be a pity if we choose the framework that happens to be the next > one to go extinct :) so Vue feels more secure than Angular but what do I > know? > > Finally, I hope the SIP, in addition to surveying existing code and > possible frameworks, should also list the deployment options we have (jetty > inside solr app, jetty separate webapp, jetty, different port, standalone > node, package system…), and recommend one. Perhaps lay out a roadmap > starting with drop-in replacement as first step? > > > When it comes to the question of covernance and where the code lives, I > came to think of another option we have not yet discussed. It goes like > this: > > Solr Admin UI could be another sub project of Lucene/Solr, as PyLucene is, > with its own git repo and its own releases. > The release would be a ZIP with the compiled UI and instructions on how to > deploy as part of Solr or standalone. > Then Solr core build would pull in the zip as a dependency and serve it up > as today or in a new way. > Benefits of this solution includes: > + The core codebase remains Java only (with versioned UI as dependency) > + The UI is still governed and released by the project > + The UI gets its own repo, and its own GitHub home, which can maybe > easier attract PRs from newcomers? > + UI can do releases out-of-band. Solr can stay on same UI-release for > several versions if it wants, and we can publish UI-only bugfixes for XSS > or whatever, with easy patch instructions > + End users may choose to disable UI in solr.in.sh and deploy the UI > release standalone, i.e. more choice > The downsides are of course > - More moving parts, separate releases, more bureaucracy > - May be a problem to obtain enough PMC members vote (ask Andi), need a > separate smoketester? > - UI is not tested as part of Solr, breaking changes may be merged > unnoticed. (This can be mitigated with e2e Jenkins tests) > > There may be downsides I have not thought of, but interested in your > thoughts > > Jan > > 22. apr. 2020 kl. 18:54 skrev Marcus Eagan <marcusea...@gmail.com>: > > Nothing is ever finished. > > Yet I agree with you one hundred percent. I don't like the idea that you > can delete a collection from the UI, but that's just me. I didn't want to > get in to the discussion until I was further along. > > Marcus > > On Wed, Apr 22, 2020 at 9:50 AM Gus Heck <gus.h...@gmail.com> wrote: > >> Re Parity: If we are going to drop a feature from the UI it should be an >> explicit decision to do so. I think until we have either >> >> 1) a decision to drop (expressed in the SIP or Jira) >> 2) a working re-implementation >> >> For each feature the new UI should not be considered finished. >> >> >> On Wed, Apr 22, 2020 at 12:14 PM Marcus Eagan <marcusea...@gmail.com> >> wrote: >> >>> Parity is not necessarily a good thing. Maintaining most of the existing >>> functionality is good. I would recommend some of it is removed because it’s >>> dangerous. >>> >>> My choice to pick up the project I did was because it was the most >>> updated of them all and I can change one variable rather than multiple >>> because the Angular name was the same. >>> >>> Thanks Jan and Houston. I need to try the project out later tonight. >>> >>> I’m happy to contribute to any of them. >>> As for the test, the scaffolds are the first step to adding tests. They >>> can be added relatively quickly but even the scaffolds ensure the >>> components compile, which is step forward for the project where it is >>> today. There are a couple months of work on it. I did not intend for >>> anything to be merged yet, but for code to exist for people to test it out. >>> >>> The Angular project is a pain. However, I will keep the project up and >>> work to support whatever the community needs. >>> >>> My goal is to get an updated Solr Admin UI Im the project to help >>> developers get started, and improve security. Whichever one the community >>> decides on, I will work with everyone to help get it done. >>> >>> Thank you, >>> >>> Marcus >>> >>> >>> On Wed, Apr 22, 2020 at 08:24 Houston Putman <houstonput...@gmail.com> >>> wrote: >>> >>>> I agree with Jan, I think we need some discussions on alternatives and >>>> the pros/cons of each before we invest in implementing a solution. >>>> >>>> I personally have the most experience with React and don't know much >>>> about other frameworks, but I'd love to understand why Angular or Vue.JS >>>> might be a better option. >>>> (Having an implementation to start with is definitely a plus, and it >>>> doesn't look like there is one for React) >>>> >>>> Yasa looks more complete than savantly-net/solr-admin to me, and >>>> definitely warrants at least a look. >>>> >>>> - Houston >>>> >>>> On Wed, Apr 22, 2020 at 7:27 AM Jan Høydahl <jan....@cominvent.com> >>>> wrote: >>>> >>>>> I spun up the proposed app for the first time today, clicked around >>>>> and browsed the code. >>>>> It appears to me that the app is far less developed than I thought, >>>>> which agrees well with only 12 commits. >>>>> The collections component only knows how to list collections, the >>>>> «create collection» button is dead etc. >>>>> It will be a HUGE effort to bring this to feature parity with current >>>>> AdminUI. >>>>> I cannot find any substantial tests other than scaffold tests >>>>> verifying that ng components are created ok. Could be because there is not >>>>> that much functionality to really test yet? >>>>> >>>>> Which makes me question again the perhaps premature decision on using >>>>> this repo as a basis. >>>>> >>>>> >>>>> So I did a quick test with the VueJS based YASA app ( >>>>> https://github.com/kezhenxu94/yasa) and got up and running in a few >>>>> minutes, with a much more feature complete UI. >>>>> It is also a complete drop-in replacement for the old UI, once >>>>> compiled. Downside is that it is older and needs upgrade and to play well >>>>> with CPF. >>>>> So let’s step back for a while and not make hasty choices too early. I >>>>> worked with VueJS in a project and really like it. Vue is the 2nd coolest >>>>> kid on the block after React >>>>> according to https://2019.stateofjs.com/front-end-frameworks/ and >>>>> Wikipedia just chose it over React for their UI makeover. >>>>> >>>>> Anyway, if you want to test YASA locally, here is a 3 minutes recipe >>>>> for doing so: >>>>> >>>>> https://gist.github.com/janhoy/0f7cddc0d92f9e53db7522fe93ff7003 >>>>> >>>>> To me, this looks like a much better starting point, and the project >>>>> has 2x the contributors, 3x the commits and a MIT license :-) >>>>> >>>>> Another reason to spend more time in SIP mode, iterating on what is >>>>> best for the project, what alternatives were considered and why certain >>>>> frameworks were selected/rejected etc etc, before spending much more time >>>>> coding. >>>>> >>>>> Jan >>>>> >>>>> > 22. apr. 2020 kl. 11:30 skrev Noble Paul <noble.p...@gmail.com>: >>>>> > >>>>> > As I see it all the 12 commits to that project is made by Jeremy >>>>> Branham. >>>>> > >>>>> > Kudos to Jan Høydahl to save Solr from potential lawsuit & >>>>> > embarrassment in the future. Awesome, I guess you are a part time >>>>> > private detective >>>>> > >>>>> > On Wed, Apr 22, 2020 at 7:25 PM Ishan Chattopadhyaya >>>>> > <ichattopadhy...@gmail.com> wrote: >>>>> >> >>>>> >>> The shoulders of the homie that put that scaffold together are >>>>> broad! Props to him. >>>>> >> Marcus, are you working with Jeremy Branham on this? >>>>> >> >>>>> >> On Wed, 22 Apr, 2020, 2:25 pm Jan Høydahl, <jan....@cominvent.com> >>>>> wrote: >>>>> >>> >>>>> >>> WRT legal aspect, the original git repo >>>>> https://github.com/savantly-net/solr-admin does not say anything >>>>> about copyright or license. I encourage you to reach out to the copyright >>>>> holder to let them/him know about your intentions and get a temporary OK. >>>>> They may later need to sign a code grant (SGA) in order for the project to >>>>> legally integrate the code. >>>>> >>> >>>>> >>> Jan >>>>> >>> >>>>> >>> 22. apr. 2020 kl. 07:42 skrev Mike Drob <md...@apache.org>: >>>>> >>> >>>>> >>> In phase 2, will the admin ui be running in the same jetty >>>>> container as the solr application? >>>>> >>> >>>>> >>> On Mon, Apr 20, 2020 at 4:35 PM Marcus Eagan < >>>>> marcusea...@gmail.com> wrote: >>>>> >>>> >>>>> >>>> SIP here: >>>>> https://cwiki.apache.org/confluence/display/SOLR/Updated+Solr+Admin+UI >>>>> >>>> >>>>> >>>> On Mon, Apr 20, 2020 at 9:32 AM Gus Heck <gus.h...@gmail.com> >>>>> wrote: >>>>> >>>>> >>>>> >>>>> If Marcus has ability to edit existing pages, why don't we >>>>> create the empty page for him and sort out access granting issues later. >>>>> I'd hate for this much needed SIP to bog down on a technical issue. >>>>> >>>>> >>>>> >>>>> -Gus >>>>> >>>>> >>>>> >>>>> On Mon, Apr 20, 2020 at 7:10 AM Jan Høydahl < >>>>> jan....@cominvent.com> wrote: >>>>> >>>>>> >>>>> >>>>>> Please retry. I gave edit access to confluence user id >>>>> ‘marcussorealheis’. >>>>> >>>>>> >>>>> >>>>>> Jan >>>>> >>>>>> >>>>> >>>>>> 20. apr. 2020 kl. 01:30 skrev Marcus Eagan < >>>>> marcusea...@gmail.com>: >>>>> >>>>>> >>>>> >>>>>> I do need help. I am not allowed to create a SIP. Or, I have >>>>> been unable to create a SIP in three previous attempts. >>>>> >>>>>> >>>>> >>>>>> Marcus >>>>> >>>>>> >>>>> >>>>>> On Sun, Apr 19, 2020 at 3:45 AM Jan Høydahl < >>>>> jan....@cominvent.com> wrote: >>>>> >>>>>>> >>>>> >>>>>>> Thanks. The PR is useful for people to try out the UI. But for >>>>> overall replacement plan I really think we neeed that SIP, do you still >>>>> need help with Confluence? >>>>> >>>>>>> >>>>> >>>>>>> Jan Høydahl >>>>> >>>>>>> >>>>> >>>>>>> 19. apr. 2020 kl. 06:30 skrev Marcus Eagan < >>>>> marcusea...@gmail.com>: >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> I hope everybody is enjoying their weekend and is in good >>>>> health. >>>>> >>>>>>> >>>>> >>>>>>> Filed a Jira, made a PR: >>>>> https://issues.apache.org/jira/browse/SOLR-14414 >>>>> >>>>>>> >>>>> >>>>>>> Still, quite a bit more work to do. I need to spend some time >>>>> on the query screen, improving the cluster view, and adding alias, and >>>>> more >>>>> tests. The last three should be pretty easy. Would probably spend a couple >>>>> weeks working on style as well, but that can be an ongoing effort, just as >>>>> making it package manager compatible and using v2 commands. There are also >>>>> many areas where the Use of TypeScript or the Angular framework will >>>>> improve. That will come with time, some involvement from a few Angular >>>>> wizards, and a bit of research. >>>>> >>>>>>> >>>>> >>>>>>> Thank you everyone, >>>>> >>>>>>> >>>>> >>>>>>> Marcus >>>>> >>>>>>> >>>>> >>>>>>> On Tue, Apr 14, 2020 at 2:01 PM Marcus Eagan < >>>>> marcusea...@gmail.com> wrote: >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> Gus, At first it looked like it let me, but today it seemed >>>>> that it did not allow me to create a SIP. >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> On Tue, Apr 14, 2020 at 8:57 AM Gus Heck <gus.h...@gmail.com> >>>>> wrote: >>>>> >>>>>>>>>> >>>>> >>>>>>>>>> First, sorry you’re having problems with Confluence. I >>>>> suspect the issue is permissions. There are only two groups allowed to add >>>>> pages to the SOLR space, “lucene” and “lucene-pmc”. I believe these >>>>> correspond to ASF LDAP groups, which would mean they include committers >>>>> and >>>>> PMC members only. We can grant you individual permission to add/edit >>>>> pages, >>>>> however; we’ve done this for a handful of others. I could do this for you, >>>>> just ping me off-thread so I can confirm your username. >>>>> >>>>>>>>> >>>>> >>>>>>>>> >>>>> >>>>>>>>> If that is the issue, then we should advertise clearly on >>>>> the SIP page that non-committers wishing to create a SIP should request >>>>> access on this list. That's probably a good mechanic because it ensures >>>>> that contact with this list is established first. And it sounds like >>>>> confluence is allowing him to start editing and then throwing away all his >>>>> work on submission which is VERY bad behavior... Possibly an INFRA ticket >>>>> if that is indeed the case... >>>>> >>>>>>>>> >>>>> >>>>>>>>> @Marcus can you confirm that you tried to create a page, it >>>>> appeared to let you and then threw out your work on submission? (or am I >>>>> reading what you wrote wrong?) >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> >>>>> >>>>>>>> -- >>>>> >>>>>>>> Marcus Eagan >>>>> >>>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> >>>>> >>>>>>> -- >>>>> >>>>>>> Marcus Eagan >>>>> >>>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>>> -- >>>>> >>>>>> Marcus Eagan >>>>> >>>>>> >>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> http://www.needhamsoftware.com (work) >>>>> >>>>> http://www.the111shift.com (play) >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> -- >>>>> >>>> Marcus Eagan >>>>> >>>> >>>>> >>> >>>>> > >>>>> > >>>>> > -- >>>>> > ----------------------------------------------------- >>>>> > Noble Paul >>>>> > >>>>> > --------------------------------------------------------------------- >>>>> > 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 >>>>> >>>>> -- >>> Marcus Eagan >>> >>> >> >> -- >> http://www.needhamsoftware.com (work) >> http://www.the111shift.com (play) >> > > > -- > Marcus Eagan > > > -- Marcus Eagan
