Ability to customize the Build and Run commands

[basiliscus]

I realize that I can add any task I need to the 'Custom Tasks' menu. However, using it for such frequent tasks as building and running is rather inconvenient.

So I suggest the following changes:

1. Ability to customize the Build command. I'd prefer running 'gradle testClasses' instead of 'gradle build' when this command is activated. Simply because testClasses does not create war archives and therefore it is much faster. Perhaps, this option can be added to the global gradle settings dialog, or to the project properties dialog.
2. Ability to customize the Run command. Ideally I'd see this featire as follows:
   • The dropdown box in the 'run' toolbar (which now looks disabled) lists all tasks defined in the module.
   • When the 'Run' command is activated, the selected task is executed.

I am willing to implement those features myself. However, before starting I'd like you to share your thoughts of it. Thanks.

[kelemen]

I had been thinking about allowing customizing the "test single" task. Mainly because that is something that you can't even workaround with custom tasks. I see that customizing other built-in tasks may have benefits (e.g.: replace "run" with "jettyRun") as well though. Mostly why I ignored this because I could not come up with a nice and clean gui. If you could create one, that would be awesome.

As for where these settings should be stored: Though some of them make sense to be defined globally, mostly I would say it is better to define these for the project. However, I want the project settings (.nb-gradle-properties) to only contain settings which can be relatively safely shared in a vcs. Project settings, as currently implemented, do not fit good for relying on multiple sources but this is something I plan to fix (I want to add the "compile on save" option).

If you plan to implement these additions, I will refactor the project settings to have a private settings as well and be able to fall-back to global settings as necessary (I will implement these changes anyway though).

[basiliscus]

I see that customizing other built-in tasks may have benefits (e.g.: replace "run" with "jettyRun") as well though.

My company project (which I am moving to gradle) has multiple run tasks per module. So such a "static" customization of the 'Run' command is unlikely to be very useful for us (it is well for the 'Build' command though). I'd prefer to have the ability to select a run configuration (like this can be done in maven netbeans projects or in plain old netbeans projects).

However, I want the project settings (.nb-gradle-properties) to only contain settings which can be relatively safely shared in a vcs.

Hmm... In my opinion the task customizations are to be stored in VCS, so everyone in the team can use them out of the box. Consider 'nbactions.xml' in maven netbeans projects.

My suggestion regarding how to customize the 'Build' command (and ok, maybe the other commands including 'Run'). Just add a dropdown box to the custom task configuration dialog. The values in the box should be: Build, Test, (Run?), Javadoc, etc. If a value is selected, this custom task will be used as the corresponding IDE command.

If you plan to implement these additions...

Have not decided yet. It depends :)

[kelemen]

I see that there are two distinct issues here:

1. The ability to be able to customize built-in tasks.
2. Creating different profiles.

The second is a harder issue but is a good generalization of what I wanted with private project properties. This way private properties can be just another profile not commited into the vcs. I will consider these possible scenarios when refactoring the project properties.

Regadless, it is not yet clear to me, how the gui should look like for editing different profiles.

[kelemen]

The second part is now implemented in master. That is, it is now possible to create different profiles for project settings.

[basiliscus]

Cool, I like the way the profiles are implemented. Once the first part is implemented and #21 is fixed, this will become a great feature.

I faced a minor issue while testing.

1. I created a profile in my multimodule project.
2. I clicked on another submodule name and tried to select the new profile, but it was not available.
3. I opened the "Properties" dialog of the selected submodule and immediately closed it.
4. After that the profile name has appeared in the select box. So I have to repeat the step 3 for each module before being able to use the feature.

[kelemen]

I had the feeling that I forgot something :). Now that you wrote this down, I know what the issue is. The set containing the configurations is separatly maintained for each project despite that subprojects in the same multi-project share the properties. However, when you open the properties window it updates the list for that project, so that is why opening the properties window helps.

It should be handled similar to the way properties are handled. Though I will not go to such a great length to ensure correctness as I have done it for the project properties. That is, if you somehow move a subproject to a different multi-project, you will have to restart NetBeans (this should be extremly rare in my opinion).

[kelemen]

Now that I think of it, do you think that the active profile should be shared across subprojects or not?

[basiliscus]

I'd prefer the profiles be shared among all modules, as it is now. The number of tasks is limited, and it is easier to maintain them in a single place.

Maybe someone (who probably has dozens of tasks) would prefer the opposite, not sure...

[kelemen]

I meant that the active (current selection) should be shared or not?

[basiliscus]

I meant that the active (current selection) should be shared or not?

So, you ask, whether the active profile should be switched when you switch the selected module, right? I'd prefer the profile not be switched. See the explanation below.

I'd prefer the profiles be shared among all modules, as it is now.

As thinking of it more, my preferences are actually slightly different... My tasks are defined in submodules, but for convenience I always run them from the root module. So when I select a profile and click the Run button, I want the same task always be executed on the root module inspite of the currently selected submodule.

I realize that these are just my preferences.

[kelemen]

I want the same task always be executed on the root module inspite of the currently selected submodule.

Gradle is evolving in a way that I don't expect this kind of behaviour to be possible (not without considerable decrease in performance) in the future. That is, currently Gradle loads each and every subproject a multi-project build contains (so the root project as well). To the best of my knowledge this will not be so in the future.

[basiliscus]

Hmm... didn't know of that (actually I'm very new to gradle). As for your question... taking into account the new perspective, I am not sure. Perhaps, the simplest solution should be chosen by now.

[kelemen]

Everything should work now and the changes are merged into master. Now every built-in task can be customized, including "test single" and "debug test single".

@basiliscus can I ask you to verify that it works as expected?

[basiliscus]

Exactly! This is a killer feature which makes your plugin perfectly convenient.

A minor issue faced:

1. In the default profile I replaced the built-in command Build with 'testClasses'.
2. Created a test profile and opened the "Manage built-in tasks" dialog for it.
3. I saw that the Build command in the new profile inherits the 'build' task. I'd expected to see that 'testClasses' is inherited.
4. Closed the dialog, selected the test profile and executed the Build command from the context menu on a module. As expected, the 'testClasses' task was executed.

[kelemen]

What is displayed is irrelevant when the "inherited" checkbox is checked. However, I intended to show the inherited value when the dialog is opened. Now I fixed this one but the content of these components will not revert to show the inherited value when you check "inherited" until you close the dialog. This is intended because while the dialog is open, you might change your mind and uncheck "inherited". In which case you probably want to go to your previous setting rather than to the inherited value.

I also wanted to add "compile on save" feature but it seems this change needs to wait because I cannot seem to find the API to be notified when a file is saved.

[basiliscus]

There is a minor issue: the list of profiles in the toolbar is unordered. Can you consider cherrypicking https://github.com/basiliscus/netbeans-gradle-project/commit/b5e9ed502279bf117d7e67bbeae30ccf3d3b14d1 to fix this.

Thanks.

[kelemen]

I have adjusted the code, so profiles are no kept sorted.