I’ve checked out the bnd repository and imported all projects in eclipse. Now I want to start an eclipse with the (slightly modified) bundles from the workspace, using an “Eclipse Application” configuration (I’ve tried “OSGi Framework” as well, doesn’t make any difference).
Problem is that the bundles from the workspace don’t appear in the “Plug-ins” tab. Obviously, only bundles from projects with Eclipse plugin nature are included here. Can anybody please give me a hint how I can include the bundles from the workspace? Everybody who has ever worked on bndtools should have faced this problem…
Bnd has its own launcher and `Eclipse Application’ and ‘OSGi Framework’ are the ones native to Eclipse.
Just for clarification: please note that you need to use the Bnd one to launch a Bnd(tools) application (including the test Eclipse instance).
Please also note that, due to some of the quirks of the way that Eclipse was designed internally, you generally can’t re-compile and re-deploy a bundle into the running test Eclipse instance as you can with other applications. If you make a change to your code while the test Eclipse is running, you will generally have to exit and restart the test Eclipse instance. There are a couple of exceptions to this (see More Facades: Streamlining Eclipse plugin dev with ExtensionFacade for more details).
Out of interest, are these bndruns hand crafted or generated (at least with respect to the list of bundles)? The Eclipse that comes up is quite old and e.g. does not support Java-17. So I cannot use it to reproduce the bnd related problem that I have with my project, because my project requires a Java-17 environment to be supported/provided by Eclipse.
We try to stay behind the Eclipse versions as long as it is feasible to allow maximum compatibility. It might be getting time to update again? It is always a painful project since the Eclipse bundles are often goofing off in their OSGi metadata, sadly requiring hand tuning.
To debug on the latest release, I startup Eclipse in debug mode and attach a remote debugger. You can use the artifacts in org.bndtools.p2 (you have to make them with gradle in that directory) if you want your local version to run.
You can start Eclipse in debug mode by editing eclipse.ini.
In Eclipse, you can then start a Remote Application debugging session. Works actually quite well. Of course your Eclipse sources are going to be off so you need to manually link them.
I’m already doing this as a workaround. Gets quite tedious though, because every time I make a change in the bnd sources in order to test something (I’m still trying to find out which data triggers the bug in the CapabilitiesComparator; seems to be some transient relationship, not as easy as I thought initially), I have to build p2 again and update bnd in eclipse (that what takes time).
Of course, the approach to support older versions of eclipse as long as possible is okay. And if the bndruns have to be created manually, it’s perfectly understandable that this is only done when really necessary.
I am looking at the CapabilitiesComparator and it is looks dreadful. It is wrong in so many places. I will make a new one. I found way too many errors and bizarre things in there. Amazed it worked so far.
Out of interest, are these bndruns hand crafted or generated (at least with respect to the list of bundles)? The Eclipse that comes up is quite old and e.g. does not support Java-17. So I cannot use it to reproduce the bnd related problem that I have with my project, because my project requires a Java-17 environment to be supported/provided by Eclipse.
I feel your pain. I had a similar problem back a couple of Eclipse revisions ago, and ended up adding (in my own working copy, never checked into Git) the necessary P2 repository for the relevant version of Eclipse and creating my own Bndrun for that version of Eclipse. Soon after (in fact, possibly as a direct result of the problem I was working on) then the team decided it was time to up the baseline version of Eclipse to the version I was testing against so that my little hack became redundant.
Also, in the Bnd workspace, we don’t use the Eclipse P2 repos directly. This is because we found them too unreliable for use in the CI tests, which would frequently fail due to P2 download failures. The workaround was that @bjhargrave would periodically generate an OBR-shaped repo from the subset of bundles that we were interested in and deploy it to JFrog, which was a lot more stable for the CI. For your own personal testing/development purposes using the P2 repos directly works fine though.
In terms of how these bndrun files are generated: mostly, it’s a matter of getting the set of -runrequires correct and then letting the resolver do its thing. This set of bundles could in theory change a little between versions, but it seems fairly stable. There are also a few little hacks that the bndtools.core project has in it to help work around a few Eclipsisms like split packages, plus the platform-specific bundles, but generally the resolver is able to figure it all out and produce the set of -runbundles that you need. The bndtools.core.test has an example of an even smaller subset of -runrequires used for testing a particular feature. So there is no technical reason why you couldn’t have another bndrun geared to start up a later version of Eclipse. We could even make a case perhaps for putting it somewhere in the Bndtools repository?
As mentioned in another topic, I eventually gave up after some hours when trying to write a configuration and installed the development version as update (and ran eclipse with remote debugging).
Given that Eclipse is an OSGi application, I still wonder whether it shouldn’t be possible to write an Eclipse plugin that simply dumps the current Eclipse configuration as a bndrun file. This could also cover situations where a problems shows up in a project context that requires additional plugins (with respect to an Eclipse default configuration).
Given that Eclipse is an OSGi application, I still wonder whether it shouldn’t be possible to write an Eclipse plugin that simply dumps the current Eclipse configuration as a bndrun file. This could also cover situations where a problems shows up in a project context that requires additional plugins (with respect to an Eclipse default configuration).
This is possible too. I have a little project in my working directory somewhere that I dubbed evloser (ie, “resolve” spelled backward), which traverses the dependency hierarchy of all the OSGi wires in the running framework and finds the roots of the dependency tree (ie, those bundles that have no capabilities attached to a corresponding requirement), then uses that to spit out a -runrequires. Wouldn’t be hard to add the other necessary fields too. If there is enough interest (and I can find the time), I can dust it off and contribute it somewhere as a beta release.
Edit: In theory: Could this be another button in the .bndrun Editor which which calculates -runrequires? (Similar like the “Resolve” Button which calculates -runbundles)
Yes, it is useful if you’ve ever had to fiddle with runbundles directly (typically due to bundles with poor metadata) and then you want to “normalise” it by back-calculating runrequires. Initially I prototyped it to help with converting a PDE launch file to a resolvable bndrun equivalent.
Possibly. One small complication is that, unlike the bnd resolve operation, evloser requires you to actually launch the bndrun, which might have side effects. I’m not sure how best to handle that from a UI perspective - maybe closer to the run/debug launch buttons than the resolve button? Or maybe as a GoGo commandlet?
