Buildship creates Eclipse Run Configurations for each task

[Prodentity]

When a task is run from the Gradle Tasks panel, an Eclipse Run Configuration is created.

If you have any number of Run Configurations in your project, this creates clutter that needs to be sorted through in order to get to your needed Run Configuration.

These Run Configurations are essentially duplicates of the task in the Gradle Tasks view panel.

If a Buildship configuration option were available, it would alleviate the clutter created by executing many Gradle Tasks from the Gradle Tasks panel.

[donat]

Just to clarify, you would like to have a Buildship configuration option to disable run configuration creation upon task execution. Is that correct?

[Prodentity]

Yes, correct. Something like: {checkbox} Create a Run Configuration when a Gradle Task is run from the Gradle Task tab.

[dumischbaenger]

I agree with Prodentitys demand. I would also prefer to turn it off.

[oehme]

Doesn't JDT also create a run configuration for every class and test you launch? Do they have a way to turn that off?

[dumischbaenger]

a) It just pollutes my run configuration. I only use Gradle tasks view panel for Gradle interaction and get a bunch of unwanted and unneeded run configurations.

b) It happened again and again that I pushed the run button to start my project but started a Gradle task.

c) It's true that JDT creates a run configuration. This configuration is created when I press the "run as java application" menu. This is useful because normally I start my application again and again. Sometimes with just a few seconds interval. But do I deploy my application every view seconds?

[edeandrea]

I somewhat agree with @oehme - this is something Eclipse does all the time even when you Run As -> JUnit Test. Eclipse creates a run configuration for everything that you do (like it or not). As @dumischbaenger states this is helpful when running an application but not necessarily when running tests or Gradle tasks. It would be an interesting thing to implement but I'm not sure it's Buildship's to implement.

[donat]

The implementation is straightforward here.

• Create a workspace preference Automatically create run configurations
• If the preference is disabled then don't persist the run configuration in DefaultGradleLaunchConfigurationManager
• Add test coverage to GradleLaunchConfigurationManagerTest

[oehme]

@donat I wouldn't add a preference. Instead, I'd change the behavior as follows:

• running a task from the tasks view does not create a run configuration
• if the user really wants one, she can create it with a right click on the task
• do create run configurations when using "Run as Gradle Test" (because that matches the JDT behavior)

[donat]

I'm a bit concerned about the usability of your proposal @oehme. Without reading some documentation I'd be a bit confused as a user when a run config is created and when is not. Besides, I think most people are fine with creating the run configurations and the rest just want to turn it off entirely. /cc @Prodentity @dumischbaenger

[oehme]

I don't really see the confusion. Run configs are generally created when I use "Run As..." on a project. That's what we would keep.

The fact that run configs are also created from the tasks view automatically has always annoyed me. Plus, there is an explicit context menu entry to create one conveniently if I really want that. But mostly it just creates unnecessary duplication, because now I have an entry both in the tasks view and in the run configuration list.

[donat]

Makes sense. Still, I'd love to hear what our users think about this plan.

[edeandrea]

Just my 2 cents...

In general I would say I'd agree to keep it working the way other things in Eclipse work. That being said - I sometimes question why Eclipse does things a certain way. I have tons & tons of run configurations that have been created that I am constantly going in & deleting because I don't like the fact that Eclipse created them.

If you are going to build out new functionality then why wouldn't you want to give your users the most flexibility possible? I think adding a preference would be useful, plus I don't think adding a preference to a preference page (that already exists) and then using that preference elsewhere within the plugin isn't a very difficult thing to do from a development perspective (of course I'm saying this without knowing anything about how your plugin codebase is structured :) ).

[oehme]

why wouldn't you want to give your users the most flexibility possible

Because it adds maintenance overhead for us and cognitive overhead for the user. We don't want Buildship to look like Super ;)

[edeandrea]

Point taken :)