Follow testRun and project launch config options.

[subhash-arabhi]

Changed the NBLaunchDelegate to use launchType instead of guessing it from file location.
bug - #353

Similarly preferProjActions is picked up launch arguments (if available) instead of guessing it
bug - #431

By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -

• are all your own work, and you have the right to contribute them.
• are contributed solely under the terms and conditions of the Apache License 2.0 (see section 5 of the license for more information).

Please make sure (eg. git log) that all commits have a valid name and email address for you in the Author field.

If you're a first time contributor, see the Contributing guidelines for more information.

If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.

PR approval and merge checklist:

1. Was this PR correctly labeled, did the right tests run? When did they run?
2. Is this PR squashed?
3. Are author name / email address correct? Are co-authors correctly listed? Do the commit messages need updates?
4. Does the PR title and description still fit after the Nth iteration? Is the description sufficient to appear in the release notes?

If this PR targets the delivery branch: don't merge. (full wiki article)

[lahodaj]

So, if I open a Maven test, go to the RUN AND DEBUG tab, and press Run and Debug, it works for me before this change, but not after it. I still think acting based in the testRun setting/value if present is correct, but interpreting a missing testRun as hard false might be(?) too much. I tried to do tri-state approach here:
https://github.com/subhash-arabhi/netbeans/compare/test-run-config-changes...lahodaj:netbeans:test-run-config-changes?expand=1

I.e. if testRun is missing, use "test run" if in test sources, and "run" if in main sources. Otherwise, use the testRun value. Using this, clicking on Run Main should work (as it has testRun when in test sources), but running the test should also work.

Please let me know what you think.

Thanks!

CC @dbalek @sdedic

[lahodaj]

To summarize, this is PR adjusts what happens when a file is open, and "Run" (or "Debug") is invoked.

Currently, both "ordinary" and "test" files can be run using the "Start Debugging" and "Run Without Debugging" actions. The server determines whether the file is run as "ordinary" (i.e. typically main method) or as test based on the location of the file. Whether this is really correct, I am not completely sure. It could be argued that test runs should only be done using the "Testing" tab or the test glyph-gutter annotations. I am not sure, although I guess I somewhat like the ability to just run test. @jisedlac, any opinion? Thanks!

There's a problem in the current implementation and that is that if a test file contains a "main" method, it cannot be run using the "ordinary" execution, as it will always be run as a test.

This PR adjusts the existing behavior to allow "ordinary" execution of files inside the test roots as follows: there's an existing testRun option recognized in the launch configuration. The interpretation of this option changes slightly:

• if the testRun option is present and false, the file will be (unconditionally) run using "ordinary" execution (i.e. commonly as a main class).
• if the testRun option is present and true, the file will be (unconditionally) run using "test" execution.
• if the testRun option is not present, then the execution will be determined based on the file location - the test execution will be used for files inside the test directory, otherwise the "ordinary" execution will be used.

This way, it is always possible to override the autodetection and say exactly what should happen by explicitly setting the testRun option.

[lahodaj]

Unless there are objections, I would like to merge this in a few days. Thanks!

[neilcsmith-net]

@lahodaj have any tests run on this? Showing as still needing approval.

[lahodaj]

@lahodaj have any tests run on this? Showing as still needing approval.

Right. I've approved the workflow. Tests ran on the previous iteration (which is invisible/hard to find, due to the squash requirement and hence force push), and the current iteration is exactly the same. So, I assume (read: hope) the tests will pass.