[bndtools launch] Tidy up launch-time JRE selection configuration

[kriegfrj]

The OSGi Launch Configuration window has a JRE tab which it inherits from the Java launch configuration window on which it is based.

However, when Bndtools launches an application, it doesn't normally use whatever is set in the JRE tab. In AbstratOSGiLaunchDelegate.getVMInstall() does the following:

1. Attempt to find the most appropriate configured VM that matches the -runee setting in the .bnd(run) file;
2. If -runee is not set, then it will try to use the Eclipse Workspace default.
3. If there is no default VM set in the Eclipse workspace, then it will use the default Java launch configuration delegate's algorithm for determining the VM to use (which includes using the configuration set in the JRE tab, if any).

So the JRE tab is literally the fallback of fallbacks. Having it there and configurable is probably a bit misleading.

I also think that AbstractOSGiLaunchDelegate (AOLD) is not doing the right thing by trying the Eclipse workspace default as the first fallback. If we're going to have a fallback at all, I think it would make most sense to use the default Java launch as the fallback - it will presumably itself fallback to the workspace default if necessary.

So there are a couple of options that we could do to fix this:

1. Get rid of the JRE tab altogether. AOLD will use -runee and -runee only, and fail with an error if none is set or if it can't find a match. The user will then need to decide if they fix -runee or add the missing JRE to their Eclipse workspace configuration.
2. As in 1, but AOLD will use the workspace default as a fallback. If it uses the fallback it could be for one of two reasons - either because no -runee is set it (in which case it should warn that none is set and it is using the default) or because no compatible VM was found (in which case it should warn that the VM is not strictly compatible with the requested EE).
3. As in 2, but AOLD will use JavaRuntime.computeVMInstall() as the fallback. This will have the effect of using the project's build-time JRE as the fallback first, and the Workspace default if no build JRE is set.
4. As in 3, keep the JRE tab, but make it read-only and attempt to synchronize it to the -runee setting.
5. As in 4, make it read-only unless no runee is set, and then allow edits if -runee is not set.

The above suggestions do not take into account technical feasibility (eg, I don't know how easy it is to simply remove the JRE tab).

Thoughts?

[rotty3000]

I'm the maven world, the project jre is determined by the maven compiler settings falling back to the maven default properties, failing back on the JVM configured to run maven which in m2e is the workspace jre. Configuring the project jre will always be overridden the next time the maven nature is refreshed since m2e tries to keep this in sync with what maven sees.

Now, the bnd maven plugins that operate on bndrun files may infer the -runee also from those same maven aspects and can opt to not specify -runee letting the inferencing do its magic.

I would expect the Eclipse launches to continue to work given those considerations. Currently it does. Please, if you change the launching logic, consider the m2e scenarios.

On Wed, May 6, 2020, 21:02 Fr Jeremy Krieg, [email protected] wrote:

The OSGi Launch Configuration window has a JRE tab which it inherits from the Java launch configuration window on which it is based.

However, when Bndtools launches an application, it doesn't normally use whatever is set in the JRE tab. In AbstratOSGiLaunchDelegate.getVMInstall() does the following:

1. Attempt to find the most appropriate configured VM that matches the -runee setting in the .bnd(run) file;
2. If -runee is not set, then it will try to use the Eclipse Workspace default.
3. If there is no default VM set in the Eclipse workspace, then it will use the default Java launch configuration delegate's algorithm for determining the VM to use (which includes using the configuration set in the JRE tab, if any).

So the JRE tab is literally the fallback of fallbacks. Having it there and configurable is probably a bit misleading.

I also think that AbstractOSGiLaunchDelegate (AOLD) is not doing the right thing by trying the Eclipse workspace default as the first fallback. If we're going to have a fallback at all, I think it would make most sense to use the default Java launch as the fallback - it will presumably itself fallback to the workspace default if necessary.

So there are a couple of options that we could do to fix this:

1. Get rid of the JRE tab altogether. AOLD will use -runee and -runee only, and fail with an error if none is set or if it can't find a match. The user will then need to decide if they fix -runee or add the missing JRE to their Eclipse workspace configuration.
2. As in 1, but AOLD will use the workspace default as a fallback. If it uses the fallback it could be for one of two reasons - either because no -runee is set it (in which case it should warn that none is set and it is using the default) or because no compatible VM was found (in which case it should warn that the VM is not strictly compatible with the requested EE).
3. As in 2, but AOLD will use JavaRuntime.computeVMInstall() as the fallback. This will have the effect of using the project's build-time JRE as the fallback first, and the Workspace default if no build JRE is set.
4. As in 3, keep the JRE tab, but make it read-only and attempt to synchronize it to the -runee setting.
5. As in 4, make it read-only unless no runee is set, and then allow edits if -runee is not set.

The above suggestions do not take into account technical feasibility (eg, I don't know how easy it is to simply remove the JRE tab).

Thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bndtools/bnd/issues/4027, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABD2TGGS3RS7HB5Y6DDMVDRQICCTANCNFSM4M2447RQ .

[pkriens]

In principle, we should only use Eclipse information & settings when it is about user preferences, not ever on something that might make a difference in the build.

The VM is clearly on this edge. I never liked the idea that we got the JRE from Eclipse (this is the native launcher's attempt, I needed to let the ProjectLauncher be in charge since the VM was already running.)

I got the feeling we should get rid of this tab. Only hesitation is that we currently do not have a VM setting except the property 'java'.

Maybe we should extend this and add a library to figure out the VMs in the environment and do a more precise selection. Windows of course is the hard part here, I think we have the code, however, in the jpm repository.

[bjhargrave]

I think if the user selects a JRE on the JRE tab, we must honor that. We can warn if the selected JRE is incompatible with -runee (if present).

When creating a new launch configuration, we can preselect a JRE based upon the -runee (if present) or the project's (holding the bnd file) configured JRE.

[bjhargrave]

I will also note that -runee is for configuring the system bundle's resource for resolve operations. It really has no meaning at runtime or necessarily in selecting a runtime. It is about defining the desired runtime for resolve operations.

It seems a bit odd that we have overloaded -runee as part of the selection of a JRE for launching, but I suppose that is useful to the user.

[stale[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.

[stale[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.

[kriegfrj]

The OSGi Launch Configuration window has a JRE tab which it inherits from the Java launch configuration window on which it is based.

However, when Bndtools launches an application, it doesn't normally use whatever is set in the JRE tab. In AbstratOSGiLaunchDelegate.getVMInstall() does the following:

1. Attempt to find the most appropriate configured VM that matches the -runee setting in the .bnd(run) file;
2. If -runee is not set, then it will try to use the Eclipse Workspace default.
3. If there is no default VM set in the Eclipse workspace, then it will use the default Java launch configuration delegate's algorithm for determining the VM to use (which includes using the configuration set in the JRE tab, if any).

So the JRE tab is literally the fallback of fallbacks. Having it there and configurable is probably a bit misleading.

I also think that AbstractOSGiLaunchDelegate (AOLD) is not doing the right thing by trying the Eclipse workspace default as the first fallback. If we're going to have a fallback at all, I think it would make most sense to use the default Java launch as the fallback - it will presumably itself fallback to the workspace default if necessary.

I think that this is the root cause of an issue that @rotty3000 has related with m2e launches and -runee inferencing. As reported by @bjhargrave in the Bnd developers Slack group:

It seems the launcher for Run as OSGi JUnit test is always using the same VM as the one running Eclipse despite what you say in the launch configuration

"[T]he same VM as the one running Eclipse" would be the workspace default. So this observation confirms the hypothesis I made all those months ago.

With the benefit of this and what else I've learned in the last 18 months, here is an evaluation of the original proposals.

So there are a couple of options that we could do to fix this:

1. Get rid of the JRE tab altogether. AOLD will use -runee and -runee only, and fail with an error if none is set or if it can't find a match. The user will then need to decide if they fix -runee or add the missing JRE to their Eclipse workspace configuration.

This won't work because in m2e land it is convenient to rely on -runee being inferenced for compatibility with command line Maven.

2. As in 1, but AOLD will use the workspace default as a fallback. If it uses the fallback it could be for one of two reasons - either because no -runee is set it (in which case it should warn that none is set and it is using the default) or because no compatible VM was found (in which case it should warn that the VM is not strictly compatible with the requested EE).

This won't work because using the workspace default as the fallback bypasses the project settings. This is counter-intuitive, and also seems to not play nicely with m2e - it seems that m2e leaves the Eclipse workspace default and configures in the individual projects (and it makes sense for m2e to do it this way).

3. As in 2, but AOLD will use JavaRuntime.computeVMInstall() as the fallback. This will have the effect of using the project's build-time JRE as the fallback first, and the Workspace default if no build JRE is set.
4. As in 3, keep the JRE tab, but make it read-only and attempt to synchronize it to the -runee setting.
5. As in 4, make it read-only unless no runee is set, and then allow edits if -runee is not set.

I believe that any of these options would fix @rotty3000's issue. For the sake of incremental improvement and fixing the issue at hand, though, I propose a 6th option: Use JavaRuntime.computeVMInstall() as the fallback and not worry about tidying up the JRE selection tab. In other words, swap these two blocks around:

https://github.com/bndtools/bnd/blob/c8a8d5978051fe6b5098d7e9a900dab5c65ec7d7/org.bndtools.launch/src/bndtools/launch/AbstractOSGiLaunchDelegate.java#L133-L149

[kriegfrj]

The above may still be an issue, but it turned out to be a red herring in @rotty3000 's case. It turns out that the Bndtools m2e code is returning the inferred -runee at this line here:

https://github.com/bndtools/bnd/blob/c8a8d5978051fe6b5098d7e9a900dab5c65ec7d7/org.bndtools.launch/src/bndtools/launch/AbstractOSGiLaunchDelegate.java#L105

This means that the two blocks I highlighted above (which come after the block that uses the -runee setting) don't actually get run.

[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.