[debug] Create debug project for launches

[kriegfrj]

We've made some progress in source lookup through previous issues/PRs like #4011. However, there are still a few problems with debugging Bnd-launched applications from within Eclipse.

One of the cool features of Eclipse debugging is being able to enter code that is compiled and executed dynamically during a debugging sessions. This allows you to do things like conditional breakpoints, inspecting the results of certain functions during execution, etc. Unfortunately, this feature is somewhat unreliable when debugging under a Bndtools launch.

Another issue is code navigation. Often I find myself navigating through code calling and inheritance hierarchies, only to hit a dead end because the class I'm after is not on a build path of any of my projects (though it is included in the runtime). I end up manually adding it to some random project's -buildpath in my workspace so that I can continue to navigate.

There are a couple of reasons for this:

1. The main reason for this is that Bndtools makes a clear separation between the run-time dependencies and the build-time dependencies. Whereas build-time dependencies (under the Bnd Bundle Path container in the Eclipse project) are available to the project's compiler, the run-time dependencies (ie, those that appear in -runpath, -runframework and -runbundles) need not necessarily be. If the expression that you wish to evaluate depends on classes that are not present on your launch project's classpath, then it won't compile. This seems to happen to me often.
2. In an extreme example of 1, it is possible to have a .bndrun file in a project that has no .bnd or an empty .bnd (which consequently will have an empty Bnd Bundle Path container). One of my workspaces is set up like this - lots of projects to build all of the individual component bundles, and then a separate "launch" project that contains my main .bndrun that pulls them all together.

Having learned how the JAR Editor works recently - by creating a hidden temp project - I thought that the same could be done for a Bnd launch. The temp project would include all of the bundles in -runfw, -runpath and -runbundles in its effective classpath, through some kind of custom container.

This approach would be an improvement, but there will still be issues due to the compiler not being OSGi-aware. This means that it won't be able to handle:

• Bundles that make use of Bundle-ClassPath (but none of us do that anyway, right? :smile:)
• Multiple bundles containing the same packages (possibly of different versions). (Note that this is also an issue with the current source lookup; see #4029)

I'm not sure if it would be possible to fix these - it might be possible to have the compiler use the bundles' wiring information at runtime to find the classes to compile against. I haven't looked into this in detail, but that would be gold standard.

[gamerson]

Hey @kriegfrj

The PDE does something exactly like what you are describing. Install Eclipse PDE plugins, then open the Plugins View. Select any plugin you see right click and select "Add to Java Workspace scope" Then you will see a new project get added to your "explorer" view called External Plugin Libraries. This is hidden by default in the Package Explorer (but there is a filter for it you can disable). But in "Project/Bndtools Explorer" it should be visible by default. You can see they have added the "plugin" to this project's classpath under the "External Plugins" custom classpath container. Now it will be indexed by the Java search engine.

Also when you create a PDE debug launch configuration this "External plugin libraries" project will automatically get added to the "Source lookup" search.

[kriegfrj]

Yes, having the bundles missing from the search scope (both during dev and debug) is also annoying.

Some questions/points for discussion:

1. Is it best to have one project per launch file (what I was originally proposing), or one for the whole workspace (like PDE)? The former will do better in the event that you have multiple different versions of a bundle/package in your workspace (searches and code navigation are more likely to find the bundle that's relevant to your current context); however will it be a problem having the explosion of projects? Also, having one for the workspace means that code navigation will be available for all bundles in the workspace.
2. If we use the one-project-per-launch approach, is it better to delete the project once the launch exits, or to leave the project in place permanently? The latter will mean code navigation is available all the time and not only while a launch is active.
3. It is possible to get Bndtools to index all the repository bundles directly and make them available to Eclipse's search without needing to create a project for them and put them on a build path. This could allow us to get code navigation but still go with temporary launch projects.

[gamerson]

Some questions/points for discussion:

1. Is it best to have one project per launch file (what I was originally proposing), or one for the whole workspace (like PDE)? The former will do better in the event that you have multiple different versions of a bundle/package in your workspace (searches and code navigation are more likely to find the bundle that's relevant to your current context); however will it be a problem having the explosion of projects? Also, having one for the workspace means that code navigation will be available for all bundles in the workspace.

So we are in control (or can be in control) of the "source lookup" director facility for the Bnd debug launches. So we are free to organize it however we see fit. The "one project" seems like easier to maintain. That one project could have one classpath container that could be used for indexing all of the 'runtime' bundles for the 'current launch'. The issue might be when you have 2 launches at the same time, that one container would have a union of the two launch runtime bundles which could lead to weird results (but maybe that is mostly unlikely?).

2. If we use the one-project-per-launch approach, is it better to delete the project once the launch exits, or to leave the project in place permanently? The latter will mean code navigation is available all the time and not only while a launch is active.

I don't like the idea of ephemeral projects, between Eclipse resource/workspace/git/builder reconciler loops, we are just asking for trouble.

3. It is possible to get Bndtools to index all the repository bundles directly and make them available to Eclipse's search without needing to create a project for them and put them on a build path. This could allow us to get code navigation but still go with temporary launch projects.

One that same "temp project" we could have another container that could be for "extended search scope" jars, etc. And in the Bnd launch source lookup, we can be sure we make sure to direct the lookup into the "current launch container" instead of "extended search scope" container. But when a launch is not in progress, the "extended search scope" container would still be populated with runtime jars that are applicable and would work with java search.

WDYT?

[kriegfrj]

Some questions/points for discussion:

1. Is it best to have one project per launch file (what I was originally proposing), or one for the whole workspace (like PDE)? The former will do better in the event that you have multiple different versions of a bundle/package in your workspace (searches and code navigation are more likely to find the bundle that's relevant to your current context); however will it be a problem having the explosion of projects? Also, having one for the workspace means that code navigation will be available for all bundles in the workspace.

So we are in control (or can be in control) of the "source lookup" director facility for the Bnd debug launches. So we are free to organize it however we see fit. The "one project" seems like easier to maintain. That one project could have one classpath container that could be used for indexing all of the 'runtime' bundles for the 'current launch'. The issue might be when you have 2 launches at the same time, that one container would have a union of the two launch runtime bundles which could lead to weird results (but maybe that is mostly unlikely?).

2. If we use the one-project-per-launch approach, is it better to delete the project once the launch exits, or to leave the project in place permanently? The latter will mean code navigation is available all the time and not only while a launch is active.

I don't like the idea of ephemeral projects, between Eclipse resource/workspace/git/builder reconciler loops, we are just asking for trouble.

3. It is possible to get Bndtools to index all the repository bundles directly and make them available to Eclipse's search without needing to create a project for them and put them on a build path. This could allow us to get code navigation but still go with temporary launch projects.

One that same "temp project" we could have another container that could be for "extended search scope" jars, etc. And in the Bnd launch source lookup, we can be sure we make sure to direct the lookup into the "current launch container" instead of "extended search scope" container. But when a launch is not in progress, the "extended search scope" container would still be populated with runtime jars that are applicable and would work with java search.

WDYT?

Just been thinking about the above and wanted to record this thought before it left me: If we could have two containers in the temp project, then maybe we could have n+1 containers, where n = the number of active launches. That possibly solves the issue that you highlighted in the first paragraph.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[github-actions[bot]]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Bnd/Bndtools or if you have a good use case for this feature, please feel free to reopen the issue with steps to reproduce, a quick explanation of your use case or a high-quality pull request.