Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please add groups for Boot Dashboard in STS just like the Run Dashboard of IDEA #604

Open
sukangfu opened this issue Feb 24, 2021 · 13 comments

Comments

@sukangfu
Copy link

Please add groups for Boot Dashboard in STS, the groups ares so helpful for our developers.
i.e.
local
--started
----Application1(4401)
----Application2(4402)
--group2
----Application3
----Application4

image

@martinlippert
Copy link
Member

@sukangfu Thanks for the enhancement request and the description, sounds indeed like a great addition to the dashboard. How do you expect the user to organize the grouping? How would a user create groups and assign projects to groups?

@sukangfu
Copy link
Author

sukangfu commented Feb 25, 2021

@martinlippert Thanks for your attention. I mean, groups for Boot Dashboard in STS will be grouping in two scenarios.
1. Default Scenario:
Projects are auto grouping by projects running status, the default groups are:
Running,
Stopped,
Not Started.
2. Customizing Scenario:
Projects are grouping by projects running status and the user created groups. First grouping by running status, second grouping by the customized groups.
The groups could be created as Working sets/Tags/Project groups. The user will select projects to assign to the groups, or define spring boot apps to the groups, just like the setting of Spring Boot App in Run configurations.
i.e. The user created groups are group1 and group2, the Boot Dashboard will be like:
local
--Running
----group1
------XxApplication1(4001)
------XxApplication2(4002)
----group2
------YyApplication1(4003)
------YyApplication2(4004)
--Stopped
----group1
------XxApplication3(4005)
----group2
------YyApplication3(4006)
------YyApplication4(4007)
--Not Started
----group1
------XxApplication4
----group2
------YyApplication5
------YyApplication6
------YyApplication7
----Other Projects
------ZzApplication1
------ZzApplication2
------ZzApplication3
Comment:
1) XxApplication1 is the project name or main class name.
2) 4001 is the server port of the project.
3) The group Other Projects auto created by STS.

Can the Boot Dashboard be set to show only projects that have main classes? We only care about those have main classes.

@martinlippert
Copy link
Member

Running,
Stopped,
Not Started.

What exactly is the difference between Stopped and Not Started?

And where would you put apps that are starting up, but are not ready yet? (in the boot dashboard, that is the time between the JVM started and the app is ready, when the spinning wheel shows up)

Can the Boot Dashboard be set to show only projects that have main classes? We only care about those have main classes.

Agree. We should keep this as a separate enhancement request, so I moved this to #605.

@sukangfu
Copy link
Author

What exactly is the difference between Stopped and Not Started?
And where would you put apps that are starting up, but are not ready yet? (in the boot dashboard, that is the time between the JVM started and the app is ready, when the spinning wheel shows up).

My initial thoughts are as follows:
image

@martinlippert
Copy link
Member

@sukangfu Thanks for the nice illustration, I think I get this. What is the use case and reason behind differentiating between the state Stopped/Finished and Not Started ? I really would like to understand the benefit of differentiating between those two states here.

At the moment, the state diagram would have a transition from Running to Stopping, and from Stopping to Not Started, from where you have a transition to Starting (when pressing the start button), then a transition to Running when the app fully started up, etc.

I assume you would also have a transition in place to move the app from Stopped/Finished to Starting again, right (skipping the Not Started state then), which would mean that an app could never reach the state Not Started again after being started at least once. So I would really like to understand the use case for that. Can you elaborate on that "why"?

@sukangfu
Copy link
Author

sukangfu commented Mar 5, 2021

@martinlippert I'm really sorry for my late reply. I'm busy these days.

I assume you would also have a transition in place to move the app from Stopped/Finished to Starting again, right (skipping the Not Started state then), which would mean that an app could never reach the state Not Started again after being started at least once.

Yes, that is true.

Can you elaborate on that "why"?

Not Started

When STS starts, all apps are assigned to group Not Started.
There are probably dozens of apps, and we only start and develop a few of them, most of which we don't need to start.

Stopped/Finished

These applications are stopped when they are developed or temporarily not needed. They are assigned to group Stopped/Finished.

During development, compared with group Not Started,we pay more attention to the apps in group Stopped/Finished.
However, if there are very few applications, it's not necessary to separate the two groups, and it's fine to use group Not Started together.

The process is updated as follow:
image

@martinlippert
Copy link
Member

I think I slowly understand the use case, that is great, and thanks a lot for the additional details. Is the group of apps that you actively work on and therefore focus on in the development cycles (starting, stopping, starting again) a specific set of projects or is this set changing every time you start your IDE?

Here is what I have in mind: Sometimes I see developers have many projects in their workspace, but they focus on just a few of them every day. But many times they focus on a specific set of projects and that set is not changing all the time.

We introduced the concept of tagging to the dashboard a long time ago. It allows you to put random tags on projects (also multiple tags on each project) and then search for tags in the dashboard, which gives you effectively something like a "focus" when looking at the dashboard. Would that help in your situation? You could tag the projects that are in your focus and have only those show up in the boot dashboard, making it super easy to start/stop/restart them, get organized, etc. What do you think about that?

Don't get me wrong here, I am not against your suggestion of introducing the grouping that you described, just trying to get to the bottom of this and discuss different options that we have. All your input here is very much appreciated.

@sukangfu
Copy link
Author

sukangfu commented Apr 9, 2021

Is the group of apps that you actively work on and therefore focus on in the development cycles (starting, stopping, starting again) a specific set of projects or is this set changing every time you start your IDE?

In fact, I pay more attention to these states: Running,Stopped/Finished. Starting and stopping are just process states.
The user's custom groups will remain unchanged, and the state groups will automatically be grouped based on the application startup state.

Would that help in your situation?

Another option, which might be useful, I think it's more intuitive to groups.

@martinlippert For this enhancement, I just want a grouping function, and the others can be refined based on your experience and understanding. I am very sorry for not replying in time. Thanks so much.

@MahatmaFatalError
Copy link

MahatmaFatalError commented Jun 18, 2021

Maybe for large multi-projects it makes sense to generally allow custom labels (show), grouping and sorting the list.
grafik

  • For CF apps, interesting candidates for a show menu would be the number of instances or JMX ssh enabled, or the plan of subscribed services. For local apps natural candidates would be the labels that appear automatically once they are set.
  • Natural candidates for sorting menu would be name (as it is right now), state, maybe also port number.
  • Natural candidates for grouping menu would be tags and state.

However, one needs to notice that there is already a grouping and even some sort of custom labels in place:
grafik

So to have a consistent UX, Docker and CF must be taken into account.

@navy1978
Copy link

navy1978 commented Jul 8, 2021

this sounds very nice!

@sukangfu
Copy link
Author

Let me restate the overall request. Add groups for Boot Dashboard in STS just like the Run Dashboard of IDEA.
image

1. Auto Grouping By lifecycle of Apps (Default groups):

App are auto grouping by the lifecycle of Apps, the default groups are:
Starting, Running(Debug/Run), Stropping, Finished, Not Started.
1.1 Apps Lifecycle.
image
1.2 The app lifecycle begins with STS startup.
1.3 Dashboard would show the groups with apps, hide the groups with no apps.
1.4 The Running group would be groups by [Run as] and [Debug as] into Run and Debug (Not Required).
1.5 Boot Dashboard UI (No Custom Groups).
image

2. Grouping by Customizing Groups:

App are auto grouping by the lifecycle of Apps and the user custom groups. Based on the apps auto grouping by lifecycle of Apps, so the custom groups would show under the lifecycle groups.
2.1 The custom groups would be defined as [New Java Working Set], and the apps would be assigned to the custom groups by selection.
image
2.2 Dashboard would show the groups with apps, hide the groups with no apps.
2.3 The Running group would be groups by [Run as] and [Debug as] into XXX_Run and XXX_Debug. XXX is custom group (Not Required).
2.4 Boot Dashboard UI (Custom Groups)
image

3. Apps in Boot Dashboard could be listed as [Run Configuration] > [Spring Boot App]?

Refer to [#605].
image

I really hope this restatement is helpful to the development, and wish to use this feature ASAP.
Please feel free to replace the design with a more reasonable one.

@martinlippert
Copy link
Member

Thanks @sukangfu for restating the enhancement request, sounds definitely useful. Unfortunately, we don't have the cycles to work on this at the moment. I probably will have to push this out to a release in the more distant future.

@sukangfu
Copy link
Author

Maybe the cycle can be simply defined as three phases: Started(Running), Finished, Not Started.

@martinlippert martinlippert removed this from the 4.13.0.RELEASE milestone Dec 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants