There is something else in the pipeline as well that might help:
biz.aQute.bnd.runtime.snapshot. It is not being built yet but you can build it
yourself in the bnd workspace. If you place that bundle in your runtime it will
make a snapshot in the current directory just before the framework stops. You
can then drag from the file system and then drop this file on
https://bnd.bndtools.org/snapshot.html
It is still under development but it provides a wealth of information. There
are also gogo commands to make intermediate snapshots. I find this an
invaluable tool for debugging OSGi issues.
Glad you like it! Looking forward to your PR's! :-)
Kind regards,
Peter Kriens
> On 15 Mar 2019, at 08:43, Bram Pouwelse <b...@pouwelse.com> wrote:
>
> Hi Peter,
>
> I actually started to play with this cool new toy yesterday and I like it.
> It gives a lot more control over the framework(s) launched than the test
> support that has always been there. Not that long ago I was looking for
> something like this but had to hand craft some code to get more than one
> framework in a test but with Launchpad I can just use a bndrun again to
> bootstrap multiple framework instances. So it was a perfect fit for my tests
> and I can get rid of some framework boostrap boilerplate :).
>
> I did run into the "Version Sensitivity" issue when trying to obtain
> ConfigurationAdmin but that's well explained on the page you just shared, if
> only I'd read that page yesterday that would've saved me some time....
>
> So this is definitely a useful tool, thanks Peter!
>
> Kind regards,
> Bram
>
>
> Op vr 15 mrt. 2019 om 08:28 schreef Peter Kriens via osgi-dev
> <osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>>:
> I've recently been working on a bndtools testing framework based on some Pax
> Exam envy. The result is _Launchpad_. It is a builder for a framework setup
> using all the information from a bnd workspace and its projects. For each
> test method you can then execute your tests without having to generate a test
> bundle. Due to some deep class loading magic, the class space of the test
> code (for example JUnit) is properly exported via the framework. Although
> there are some pitfalls, sharing the classes this way works quite well.
>
> Launchpad also contains an injector that you can use to inject services and
> some key OSGi objects like BundleContext in your test object. A large number
> of utility methods on Launchpad provide conveniences for testing. For
> example, you can also hide services with one call.
>
> Launchpad is agnostic of a testing framework. It has been tested with JUnit
> but TestNG or other frameworks should be no problem.
>
> This is all documented:
> https://bnd.bndtools.org/chapters/315-launchpad-testing.html
> <https://bnd.bndtools.org/chapters/315-launchpad-testing.html>
>
> This is an ambitious test environment. There is now experience at one of my
> customers but it clearly needs to go to a learning period. Almost all of what
> is documented is in 4.2.0 which is just released, if you want the absolute
> latest get the 4.3.0 snapshot.
>
> Launchpad is developed for the bnd Workspace model. I think it can be adapted
> to the Maven model with the bndrun files since this mimics a Workspace
> beneath the covers. However, that might require some work and surely some
> documentation. Volunteers welcome.
>
> Let me know if this is useful and file issues on
> https://github.com/bndtools/bnd/issues
> <https://github.com/bndtools/bnd/issues> when there are issues or really good
> ideas.
>
> Kind regards,
>
> Peter Kriens
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <https://mail.osgi.org/mailman/listinfo/osgi-dev>
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
