All CLA requirements met.

@claycephas thanks for the PR. A little concern about the option classPathsToRemove, can you list some scenarios that needs this requirement?

When debugging my maven-based project with VS Code, it is including test classes in the classpath. However, IntelliJ and Eclipse don't include those test classes in the classpath. I thought the classPathsToRemove could be a temporary workaround for issues like this until a more permanent solution is found. I see it as an override so that users have the ability to have some control but without having to list every single class path in the classPaths config setting.

Including test classes in auto resolved maven classpaths looks like a bug. I open a bug for this. #111

And the existing classPaths option is always overriding the auto resolved classpaths, that's not good.
I'm thinking whether it's necessary to expose multiple classpaths options to user because we want to keep the configurations as simple as possible. Three classpaths options could confuse the users.

if we change the current classPaths behavior to merge instead of overriding, do you think is that OK?

How about add a flag option to turn auto resolved true/false and classPaths option always merge with resolved classpaths.
If the flag is false, resolved classpaths is empty, classPaths option behavior just like override.
The flag default to true if ignore, less confusing.

@claycephas @jopbrown Your suggestion could be a choice. And i also find a new choice to keep compatible with current behavior.

Reference to New Debug Configuration action in eclipse, it will persist the auto resolved class paths in configuration file, and user can add/remove the class paths there. Maybe we could take the similar policy. We could let the debugger to save the auto resolved classpaths when new a launch.json file, then the user could add/remove the classpaths in launch.json directly.

@testforstephen
If the project setting change, will persisted class paths in launch.json auto update too?
And I think leave a long list of resolved class paths in launch.json is more confuse.
As an user, I don't care what auto resolved class actually is, just keep sync with maven, and be able to add/remove custom class paths.
It will be complicated for me to update launch.json everytime when project setting change.

@testforstephen Regarding placing generated classpaths in launch.json:
There's already a generated .classpath file that lists all the classpaths. I'd be hesitant to duplicate the classpaths in the .vscode/launch.json file. That'd mean that dependencies would effectively be duplicated in pom.xml, .classpath, and launch.json. Typically launch.json is source-controlled and typically generated code is not placed in source control.

@jopbrown Regarding your suggestion, there'd be no way to remove a specific problematic classpath (e.g. like test-classes) without having to list all the rest (which is over 200 in my case).

The thing I like about classPathsToAdd and classPathsToRemove is that they're explicit in their intentions and allow lots of flexibility to users when they need a workaround for cases like #111.

@claycephas We're supporting java 9, it uses a new option module-path, let's hold on this PR first until we get a reasonable solution about customizing modulePaths/classPaths.