Skip to content
This repository has been archived by the owner on Jul 13, 2022. It is now read-only.

Enhancement: Configure "Run Spring Boot" to only consider classes with @SpringBootApplication annotation #323

Open
davidmichaelkarr opened this issue Sep 24, 2018 · 7 comments

Comments

@davidmichaelkarr
Copy link

I work on several SpringBoot projects. It's very convenient to be able to run or debug the app with a single key sequence.

Today I started work on a utility class in the project that has a "main()" method. It's only there in src/test/java to be used as an analysis task in the build. Now, when I try to run my SpringBoot application, it asks me which class I want to use, between the original "Application" class with the "@SpringBootApplication" annotation, or my utility class that I would never run as a SpringBoot application.

This is an unfortunate annoyance. I would imagine it's entirely possible some person might have some need to run a class without a @SpringBootApplication annotation as a SpringBoot application, but it seems pretty implausible to me.

I wish there was a configuration flag that would control this, so I could tell Spring IDE to not even ask me to use a class for running SpringBoot that doesn't have that annotation.

@kdvolder
Copy link
Contributor

Sounds like a good idea. And thanks for providing some details about your specific use case too. That gives us also something to work with in terms of considering alternatives (e.g. not searching for main methods in the test source might be one alternative that would slve your specific problem too, but might be much easier/efficient to implement).

@kdvolder
Copy link
Contributor

kdvolder commented Oct 3, 2018

Just thought of something. I would expect that once a launch configuration was created for your app, the launch config would specify the main type to run. So you shouldn't be asked which class to run the next time. Is this not the case? If so can you add some detailed steps (which things you select and which menus you click/invoke and in what order)? I would like to understand the exact sequence that makes this 'choose main type' dialog popup repeatedly for you (I don't think it would happen, for example, if you launched the app by clicking the start button in the boot dashboard).

@davidmichaelkarr
Copy link
Author

davidmichaelkarr commented Oct 3, 2018 via email

@kdvolder
Copy link
Contributor

kdvolder commented Oct 4, 2018

Okay so perhaps we could somehow make this work more as it was intended and have the key combo you use, to run the existing configuration instead of trying to create another one (is that what it is doing?).

But to investigate this further I'd need to be able to actually do exactly what you do and then step some things with the debugger to see what is exactly going on.

To make sure we are on the same page. Please confirm that I'm understanding it correctly:

  1. The key you are pressing is the one shown in screenshot below
  2. When you press the keystroke, your editor has the UI focus.

Since commands bound to keys tend to be sensitive to context, such as editor focus and element selection in various views... It would also be good to know... is there an active selected element(s) in the package or project explorer at the exact time when you press the key?

debug-boot-app-keybinding

@davidmichaelkarr
Copy link
Author

I don't know how I could confirm whether it's trying to create a new launch config.

Yes, those are the two keys I would press, to either run it in debug or not, and the editor would be showing a source file from the application.

I don't know whether a particular element would be selected in the package or project explorer at this time.

@kdvolder
Copy link
Contributor

kdvolder commented Oct 4, 2018

I don't know how I could confirm whether it's trying to create a new launch config.

Right, I wasn't really expecting that you would. But it is something I have to try and figure out. So that was more of a question/theory for me to verify once I get down to debugging this.

Thanks, I think I have enough information now to debug this.

@davidmichaelkarr
Copy link
Author

And if it matters, I've now evolved my code to the point where I don't need this anymore. :) It was too painful overall to have multiple entrypoints, so I simply added the meat of the additional entrypoint as an additional component and changed the main entrypoint to check for command-line parameters, which makes it use the other code.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants