[jira] [Comment Edited] (SOLR-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091010#comment-17091010
]
Marcus Eagan edited comment on SOLR-14414 at 4/24/20, 2:49 AM:
---
Ok Tomas. I intend to agree broadly. I even filed the disabled PR. It will
be reviewed and merged sooner than the UI for sure.
I think that it's fine if the package is pulled in as a pinned version and
included in the CI pipeline. I'm particularly not looking forward to
working with Noble but I hope that we can be respectful to drive this
project to completion. That way, the admin UI can iterate faster. But
perhaps that should be a future state because that requires a lot more work
and bureaucracy from someone here. I'm happy to do a lot of the leg work
on the actual build, recruit devs to pitch in, and even host a server
teaching people who to use the Admin UI. If the desire is to have it live
in a separate repository, then [~janhoy] can you work
on this ASAP.
Jeremy, the developer who originally started the Angular project and wrote
the first page of the project that I have been building upon, and I have
discussed the effort and regular meetings. I think we could move really
fast working together, but I won't be able to say how fast until the end
of next week.
On Thu, Apr 23, 2020 at 4:10 PM Tomas Eduardo Fernandez Lobbe (Jira) <
was (Author: marcussorealheis):
Ok Tomas. I intend to agree broadly. I even filed the disabled PR. It will
be reviewed and merged sooner than the UI for sure.
I think that it's fine if the package is pulled in as a pinned version and
included in the CI pipeline. I'm particularly not looking forward to
working with Noble but I hope that we can be respectful to drive this
project to completion. That way, the admin UI can iterate faster. But
perhaps that should be a future state because that requires a lot more work
and bureaucracy from someone here. I'm happy to do a lot of the leg work
on the actual build, recruit devs to pitch in, and even host a server
teaching people who to use the Admin UI. If the desire is to have it live
in a separate repository, then @Jan Høydahl can you work
on this ASAP.
Jeremy, the developer who originally started the Angular project and wrote
the first page of the project that I have been building upon, and I have
discussed the effort and regular meetings. I think we could move really
fast working together, but I won't be able to say how fast until the end
of next week.
On Thu, Apr 23, 2020 at 4:10 PM Tomas Eduardo Fernandez Lobbe (Jira) <
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
> Attachments: QueryUX-SolrAdminUIReboot.mov
>
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can
[jira] [Comment Edited] (SOLR-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089106#comment-17089106
]
Marcus Eagan edited comment on SOLR-14414 at 4/21/20, 10:40 PM:
[~dsmiley] I don't think the Admin UI, such a use-case specific and widely used
functionality, falls in the same category as these other generic and external
tools. As for the gap discussion, I will leave to [~ichattopadhyaya].
Solr deciding to keep the old UI in favor of a new UI that is secure will have
bad consequences for its users. For one, many of them working in highly
scrutinizing or secure environments will never be able to run it. If they wish
to, they will be bogged down by months of approvals and paperwork. Secondly, an
external UI application will likely not be a part of Apache's CI pipeline. I am
happy to maintain a CI pipeline for the UI, though, I suppose.
was (Author: marcussorealheis):
[~dsmiley] I don't think the Admin UI, such a use-case specific and widely used
functionality, falls in the same category as these other generic and external
tools. As for the gap discussion, I will leave to [~ichattopadhyaya].
Solr deciding to keep the old UI in favor of a new UI that is secure will have
bad consequences for its users. For one, many of them working in highly secure
environments will never be able to run it. If they wish to, they will be bogged
down by months of approvals and paperwork. Secondly, an external UI application
will likely not be a part of Apache's CI pipeline. I am happy to maintain a CI
pipeline for the UI, though, I suppose.
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087252#comment-17087252
]
Marcus Eagan edited comment on SOLR-14414 at 4/20/20, 1:26 AM:
---
{quote}Solr Developers are mostly backend developers. We have very little
experience in building UI. We are already getting crushed under the weight of a
very large codebase (mostly back end). We do not want to burdened with another
131 files which most developers in this group cannot understand or
maintain.{quote}
[~noble.paul] This PR will replace the current UI files, which are mostly
untestable, end of life, and not supported by anyone.
was (Author: marcussorealheis):
>Solr Developers are mostly backend developers. We have very little experience
>in building UI. We are already getting crushed under the weight of a very
>large codebase (mostly back end). We do not want to burdened with another 131
>files which most developers in this group cannot understand or maintain.
[~noble.paul] This PR will replace the current UI files, which are mostly
untestable, end of life, and not supported by anyone.
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087262#comment-17087262
]
Marcus Eagan edited comment on SOLR-14414 at 4/20/20, 1:26 AM:
---
{quote}NO. We will either fix bugs in the current UI or remove it
altogether.{quote}
:) This is effectively a "fix[ing of the] bugs" in the current UI. I did not
change much of the design. Kept the framework (in name), preserved most of the
design except the really confusing or outdated bits, and added basic tests with
the intention fo adding more. If I remove the package management piece from the
discussion, I don't see any work from you at all. I'm sure I could work with a
few others in the group to help with the ongoing maintenance of the UI,
particularly those interested in security and usability of Solr. There are
quite a few committers who focus on those areas.
>An admin UI is a nice to have feature and not a critical part of a search
>engine
[~noble.paul]Nor is a package management system. It's also a nice to have.
There are many ways and many people on the team that could review or evaluate
the tool for functionality or bugs. It is still a work in progress, and I don't
think I have to work with you on getting it implemented as a package. It can
more easily be started by Jetty. All of the tests and start commands can drop
into the existing pipeline. My offer to add it as a package was an attempt to
create a package that almost everyone would use, and to make the UI a
first-class citizen there, so it might one day be easy for a UI contributor to
make a browser for the package manager itself. If you do not want to
collaborate, that is fine by me.
was (Author: marcussorealheis):
{{NO. We will either fix bugs in the current UI or remove it altogether.}}
:) This is effectively a "fix[ing of the] bugs" in the current UI. I did not
change much of the design. Kept the framework (in name), preserved most of the
design except the really confusing or outdated bits, and added basic tests with
the intention fo adding more. If I remove the package management piece from the
discussion, I don't see any work from you at all. I'm sure I could work with a
few others in the group to help with the ongoing maintenance of the UI,
particularly those interested in security and usability of Solr. There are
quite a few committers who focus on those areas.
>An admin UI is a nice to have feature and not a critical part of a search
>engine
[~noble.paul]Nor is a package management system. It's also a nice to have.
There are many ways and many people on the team that could review or evaluate
the tool for functionality or bugs. It is still a work in progress, and I don't
think I have to work with you on getting it implemented as a package. It can
more easily be started by Jetty. All of the tests and start commands can drop
into the existing pipeline. My offer to add it as a package was an attempt to
create a package that almost everyone would use, and to make the UI a
first-class citizen there, so it might one day be easy for a UI contributor to
make a browser for the package manager itself. If you do not want to
collaborate, that is fine by me.
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the
[jira] [Comment Edited] (SOLR-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087262#comment-17087262
]
Marcus Eagan edited comment on SOLR-14414 at 4/20/20, 1:25 AM:
---
{{NO. We will either fix bugs in the current UI or remove it altogether.}}
:) This is effectively a "fix[ing of the] bugs" in the current UI. I did not
change much of the design. Kept the framework (in name), preserved most of the
design except the really confusing or outdated bits, and added basic tests with
the intention fo adding more. If I remove the package management piece from the
discussion, I don't see any work from you at all. I'm sure I could work with a
few others in the group to help with the ongoing maintenance of the UI,
particularly those interested in security and usability of Solr. There are
quite a few committers who focus on those areas.
>An admin UI is a nice to have feature and not a critical part of a search
>engine
[~noble.paul]Nor is a package management system. It's also a nice to have.
There are many ways and many people on the team that could review or evaluate
the tool for functionality or bugs. It is still a work in progress, and I don't
think I have to work with you on getting it implemented as a package. It can
more easily be started by Jetty. All of the tests and start commands can drop
into the existing pipeline. My offer to add it as a package was an attempt to
create a package that almost everyone would use, and to make the UI a
first-class citizen there, so it might one day be easy for a UI contributor to
make a browser for the package manager itself. If you do not want to
collaborate, that is fine by me.
was (Author: marcussorealheis):
>NO. We will either fix bugs in the current UI or remove it altogether.
:) This is effectively a "fix[ing of the] bugs" in the current UI. I did not
change much of the design. Kept the framework (in name), preserved most of the
design except the really confusing or outdated bits, and added basic tests with
the intention fo adding more. If I remove the package management piece from the
discussion, I don't see any work from you at all. I'm sure I could work with a
few others in the group to help with the ongoing maintenance of the UI,
particularly those interested in security and usability of Solr. There are
quite a few committers who focus on those areas.
>An admin UI is a nice to have feature and not a critical part of a search
>engine
[~noble.paul]Nor is a package management system. It's also a nice to have.
There are many ways and many people on the team that could review or evaluate
the tool for functionality or bugs. It is still a work in progress, and I don't
think I have to work with you on getting it implemented as a package. It can
more easily be started by Jetty. All of the tests and start commands can drop
into the existing pipeline. My offer to add it as a package was an attempt to
create a package that almost everyone would use, and to make the UI a
first-class citizen there, so it might one day be easy for a UI contributor to
make a browser for the package manager itself. If you do not want to
collaborate, that is fine by me.
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it
[jira] [Comment Edited] (SOLR-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087275#comment-17087275
]
Marcus Eagan edited comment on SOLR-14414 at 4/20/20, 12:41 AM:
{quote}I have not seen a single justification on why we should have this code
inside our codebase other than your desire to do so.{quote}
[~noble.paul] It is currently in the codebase. Many of the other projects that
you are talking about are not built specifically for Solr. They work with other
applications as well, and are somewhat generic in design. The Solr Admin UI is
tightly coupled with Solr in design and functionality. Naggit is for parsing
JSON streams. Spatial4J is general purpose geospatial library, and Hadoop is
for a lot of anything, certainly not just Solr. Your point about the *Solr*
Admin UI is not analogous.
{quote}NO. We clearly said that it is possible to have a new UI shipped with
Solr. Do the users care if the code lives inside the Solr codebase? I don't
think so.{quote}
Some do because of licensing concerns, I will confirm for you.
Also, I don't know if you are typing the "NO."s intentionally, but if you are,
it does not feel very collaborative or congenial. This project is managed by a
community of committers and contributors, of which you are one. I am also one.
Maybe we are not equal contributors, but we all deserve respect and the
consideration of multiple members of the community, not only two that work very
closely together, when proposing a major change intended to benefit the
everyday users of the software.
was (Author: marcussorealheis):
>I have not seen a single justification on why we should have this code inside
>our codebase other than your desire to do so.
[~noble.paul] It is currently in the codebase. Many of the other projects that
you are talking about are not built specifically for Solr. They work with other
applications as well, and are somewhat generic in design. The Solr Admin UI is
tightly coupled with Solr in design and functionality. Naggit is for parsing
JSON streams. Spatial4J is general purpose geospatial library, and Hadoop is
for a lot of anything, certainly not just Solr. Your point about the *Solr*
Admin UI is not analogous.
>NO. We clearly said that it is possible to have a new UI shipped with Solr. Do
>the users care if the code lives inside the Solr codebase? I don't think so.
Some do because of licensing concerns, I will confirm for you.
Also, I don't know if you are typing the "NO."s on purpose, but if you are, it
does not feel very collaborative or congenial. This project is managed by a
community of committers and contributors, of which you are one. I am also one.
Maybe we are not equal contributors, but we all deserve respect and the
consideration of multiple members of the community, not only two that work very
closely together, when proposing a major change intended to benefit the
everyday users of the software.
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is
[jira] [Comment Edited] (SOLR-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087239#comment-17087239
]
Noble Paul edited comment on SOLR-14414 at 4/19/20, 10:48 PM:
--
Hi Marcus
Solr Developers are mostly backend developers. We have very little experience
in building UI. We are already getting crushed under the weight of a very large
codebase (mostly back end). We do not want to burdened with another 131 files
which most developers in this group cannot understand or maintain.
As ishan said, we can ship the UI along with our distributions (if we have
consensus) . I STRONGLY OPPOSE committing this to our codebase.
was (Author: noble.paul):
Hi Marcus
Solr Developers are mostly backend developers. We have very little experience
in building UI. We are already getting crushed under the weight of a very large
codebase (mostly back end). We do not want to burdened with another 131 files
which most developers in this group cannot understand or maintain.
As ishan said, we can ship the UI along with our distributions (if we have
consensus) . But, I STRONGLY OPPOSE committing this to our codebase.
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now. It
> can quickly be modified to start as a part of the typical start commands as
> it approaches parity. I expect there will be a lot of opinions. I welcome
> them, of course. The community input should drive the project's success.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087136#comment-17087136
]
Marcus Eagan edited comment on SOLR-14414 at 4/19/20, 6:51 PM:
---
[~noble.paul] Why is that? What's the technical justification, which is
required for a {{-1}}?
was (Author: marcussorealheis):
[~noble.paul] Why is that? What's the technical justification, which is
required for a -{{1}}?
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now.
> One day, it will start as a part of the typical start commands. I expect
> there will be a lot of opinions. I welcome them, of course. The community
> input should drive the project's success.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14414) New Admin UI
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17087136#comment-17087136
]
Marcus Eagan edited comment on SOLR-14414 at 4/19/20, 6:50 PM:
---
[~noble.paul] Why is that? What's the technical justification, which is
required for a -{{1}}?
was (Author: marcussorealheis):
[~noble.paul] Why is that? What's the technical justification, which is
required for a `-1`?
> New Admin UI
>
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now.
> One day, it will start as a part of the typical start commands. I expect
> there will be a lot of opinions. I welcome them, of course. The community
> input should drive the project's success.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-14414) New Admin UI - Removes EOL Code
[
https://issues.apache.org/jira/browse/SOLR-14414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17086575#comment-17086575
]
Marcus Eagan edited comment on SOLR-14414 at 4/18/20, 6:23 PM:
---
Does anyone know a quick way to add Apache license header to every file. I can
do it but was curious if someone else out there wrote some PERL to do this or
loves adding license files.
https://github.com/apache/lucene-solr/pull/1438
was (Author: marcussorealheis):
Does anyone know a quick way to add Apache license header to every file. I can
do it but was curious if someone else out there wrote some PERL to do this or
loves adding license files.
> New Admin UI - Removes EOL Code
> ---
>
> Key: SOLR-14414
> URL: https://issues.apache.org/jira/browse/SOLR-14414
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: Admin UI
>Affects Versions: master (9.0)
>Reporter: Marcus Eagan
>Priority: Major
>
> We have had a lengthy discussion in the mailing list about the need to build
> a modern UI that is both more security and does not depend on deprecated, end
> of life code. In this ticket, I intend to familiarize the community with the
> efforts of the community to do just that that. While we are nearing feature
> parity, but not there yet as many have suggested we could complete this task
> in iterations, here is an attempt to get the ball rolling. I have mostly
> worked on it in weekend nights on the occasion that I could find the time.
> Angular is certainly not my specialty, and this is my first attempt at using
> TypeScript besides a few brief learning exercises here and there. However, I
> will be engaging experts in both of these areas for consultation as our
> community tries to pull our UI into another era.
> Many of the components here can improve. One or two them need to be
> rewritten, and there are even at least three essential components to the app
> missing, along with some tests. A couple other things missing are the V2 API,
> which I found difficult to build with in this context because it is not
> documented on the web. I understand that it is "self-documenting," but the
> most easy-to-use APIs are still documented on the web. Maybe it is entirely
> documented on the web, and I had trouble finding it. Forgive me, as that
> could be an area of assistance. Another area where I need assistance is
> packaging this application as a Solr package. I understand this app is not in
> the right place for that today, but it can be. There are still many
> improvements to be made in this Jira and certainly in this code.
> The project is located in {{lucene-solr/solr/webapp2}}, where there is a
> README for information on running the app.
> The app can be started from the this directory with {{npm start}} for now.
> One day, it will start on its own. I expect there will be a lot of opinions.
> I am prepared.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
