Use custom debug model

[awisniew90]

This PR creates and uses a new custom debug configuration rather than using the Remote Java Application configuration. The main advantages to this are:

1. Our debug configuration is now integrated within our custom Liberty launch configuration. This includes a "Source" tab on our launch configuration dialog where source paths can be added to the source lookup list.
2. We proactively look for project dependencies that are open projects in the same workspace and automatically add them to the default source lookup list.
3. We can directly control the timeout when trying to attach the debugger to the running JVM. This is useful if we need to tune things to allow larger applications to start. The timeout is set to 60 seconds for now.

Some notable changes:

1. The custom debugger requires an ILaunch object to which the debug target is attached. We currently only have an ILaunch object when we run a "Start..." or "Debug..." action. This is because a "launch" is created when we click "Run" or "Debug" from the dialog. That launch is then routed to our LaunchConfigurationDelegateLauncher. In order to get this to work, we need to "launch" a configuration on each action. To do this, I refactored our action launch classes (e.g. StartAction) to lookup the configuration for the project and run DebugUITools.launch(configuration, mode) instead of starting dev mode directly. As a consequence, all actions create an ILaunch object which then gets routed to our LaunchConfigurationDelegateLauncher. The "start dev mode" logic has now been moved over to the delegate. "

This change does not change any external behavior and if anything, it keeps our action flow consistent. We now always "launch" a configuration which always routes to the delegate which is the single location for our "start dev mode" logic.

2. We have two new classes that are associated with the behavior of our new debug launcher. These classes are added to our plugin.xml as extension points.

a. LibertySourcePathComputer - This class contains the logic to create the default source lookup path list. It first uses eclipse JDT APIs to get classpath entries for the project. It then uses m2e for maven projects and gradle tooling for gradle projects to get a list of project dependencies and then checks to see if the dependency exists in the workspace using the artifact coordinates.

b. LibertySourceLookupDirector - This class may not be necessary for what we are doing, but the logic is trivial... it creates a "director" that gathers a list of source lookup "participants" which I believe determine what type of source lookups to create. We are only using the basic JavaSourceLookupParticipant which is for Java code.

3. One test has been added to the multi mod tests that will start the war module project and make sure the jar project is in the source lookup list.

NOTE: The source lookup only works ATM for dependencies that are Maven projects... in other words we properly get the list of dependencies for both Maven and Gradle projects, BUT only m2e has APIs that will look up projects in the workspace based on artifact coordinates.... and of course, it only looks up maven projects.... So a gradle app with a dependency that is a maven project will work just fine. but if the dependency project is a gradle app, that dependency app will not be added to the source lookup list.

[scottkurz]

Like I mentioned in my StartAction comment, I think I get and like the refactoring overall.

This maybe should not be public. Maybe it should be named 'startViaDevModeOperations' or something different than the method name in DevModeOperations

[awisniew90]

launchDevMode ?

[scottkurz]

sure

[scottkurz]

Do you still need the RB here? Or could these now be removed with the Import-Pkg?

[awisniew90]

Short answer is I tried without success.... we are importing some org.apache.maven packages which are not found if you try to add them in the Import-Pkg section rather than having the m2e bundles defined... can't say I understand why... As for the other two bundles, we are calling methods on implicit objects rather than creating the objects first. So we arent actually importing packages in the classes. (e.g. object.getSomething().someMethod() ).

[scottkurz]

OK.. it's OK to use the Require-Bundle for the two m2e bundles.

As far as the other two...it sounds like you're saying that you can't easily see at compile time what classes/pkgs are needed to be imported? That in and of itself is arguably not a reason to use RB vs ImportPkg. Is it just one or two packages ? I could see trying once, twice, and then if there's a third just saying let's use RB?

However we do it can we avoid dups across RB and IP? Eg. the IP for m2e should be removed and maybe the swt custom one?

[scottkurz]

Should we add the exit trace too here?

[scottkurz]

Closing, superseded by #458