It's finally here, the first public release of Amdatu Bootstrap! Amdatu Bootstrap is the easiest way to get started with OSGi development. It is a tool that helps you to setup Bndtools projects. Instead of Googling and copy-pasting your way to a new project, this tool sets up projects interactively.
Some of the things Amdatu Bootstrap can do:
- Add dependencies for often used libraries
- Setup run configuration for often used libraries
- Create template files to supercharge development
- Manage versions in your workspace
- Baseline bundle and package versions
- Create your own plugins
Amdatu Bootstrap is based on bnd and should be used together with Bndtools. Below are some videos that show what Bootstrap can do. If you just want to get started, download the release now.
Amdatu Bootstrap from Luminis Technologies on Vimeo.
Creating Amdatu Bootstrap Plugins from Luminis Technologies on Vimeo.
Sharing Amdatu Bootstrap Plugins from Luminis Technologies on Vimeo.
A bit of history
The birth of Amdatu Bootstrap was during my Christmas holidays in 2013. In the past I had worked on JBoss Forge, which is an interactive shell to setup Java EE projects. Because all my work had switched to OSGi I couldn't really use Forge anymore (Forge is Maven based). The great thing in Forge was that it was very easy to build plugins, which allowed me to create a plugin for anything that bothered me during development of projects. I missed this concept, because it makes just as much sense in an bnd/Bndtools world. Although Bndtools is great, it's based on Eclipse RCP (it's an Eclipse plugin), which makes it quite difficult to extend.
During the holidays I felt like experimenting a bit, and decided to try to create a command line tool that was extremely pluggable, based on OSGi. New commands should be added by just adding new OSGi services. Based on the simple whiteboard pattern I had the plugin system itself working in no time. The Gogo shell already made it easy to add console commands, and I added some APIs to interact with the user using a prompt interface.
To actually make some useful plugins, I created some more APIs to easily work with bnd workspaces; add dependencies, create run configurations etc. Plugins would just have to use those simple APIs, instead of the super powerful, but not so easy to understand bnd API.
At the end of the holiday, I had a proof of concept working. I started showing the project (which was really just an experiment so far) to colleagues at Luminis Technologies, and we decided it might have potential to actually become a useful tool, and made it an Amdatu project. In the next few months I added more APIs, more plugins and it soon started to become useful for doing real work on real projects. Luminis Technologies colleague Jago de Vreede implemented some very useful plugins, including the baselining plugin which is still one of the most used features.
Out of nowhere (the project was never announced anywhere yet) we received a bunch of pull requests from Bram Pouwelse, which is now one of the most awesome Amdatu contributors, who has had an important role in all the Bootstrap development from that point on. With a small group of contributors we managed to really create something useful in the months that followed.
API design - taking the bitter pill
While more plugins were added, our ideas of what Bootstrap should do became more demanding. One of the important issues was that it should be easier to use Bootstrap from the shell, by adding things like command and argument completion. This was problematic with the API at the time, because all interaction with the user was done on-demand by invoking the Prompt API. This means we didn't have any meta model that described a plugin's arguments. Marcel Offermans and me started experimenting with a meta model that described plugins, which was based on Apache Commons CLI. This was a huge step forward, but was still mostly based on Strings. After showing the ideas to Peter Kriens (creator of bnd), he shared some great ideas about using interfaces to describe command arguments. After many iterations of fine tuning the API, we finally got to a point where it worked really easy for plugin developers, while containing all static metadata about plugins.
This new API did require refactoring all existing plugins, and rewriting a large part of the core of Bootstrap. This was a bitter pill to swallow, but looking back, I'm happy we took a few more months to do this work instead of rushing a release. New idea need lots of experimentation, and failing many times is part of that. Accepting this will make the end result much better however.
From command line to web based
Amdatu Bootstrap was designed to be used from the command line from the beginning. The main reason for this is that it is simple, and we didn't want plugin developers to care about UI. Although our API became better over time, it proofed to be really difficult to create a powerful console that worked well on all platforms. There are several libraries available to help with this, but it would still require a significant amount of work to really get this to work well. With our new API we had a much better meta model describing plugins, and I started wondering if it would be feasible to create a dynamic user interface in the browser. After lots of experimenting during traveling to conferences in the September-Oktober timeframe I created a web UI based on TypeScript, AngularJS, WebSockets based on Atmosphere and Rx. This worked so well that we decided to drop support for the console entirely and focus on the web UI. This allowed us to do things that were not possible in the console, making a much nicer user experience. The great thing about this was that we didn't have to change the plugin API at all, which also proofed that we finally got the API right.
The reason to create a Web UI instead of UI technology X (e.g. JavaFX) is simply experience. Most Bootstrap committers work with web technology on a daily base, while JavaFX would be something entirely unknown.
Architecture
OSGi makes building a tool like Bootstrap easy. Plugins are simply registered as OSGi services and this allows the core to know about the plugins. Plugins can not only provide end-user commands, but also provide services to other plugins. Again, by just registering more services in the Service Registry. We didn't have to create anything to make this plugin mechanism work. New plugins can also be added by just adding a new JAR file. No magic classpath scanning, no custom classloaders and never a restart during development. Not that this is any news, but OSGi really pays of here. On a high level, Bootstrap's architecture can be described as the diagram below.
Bootstrap Core provides APIs to access plugins, and APIs for plugins to make common tasks easy in code, such as adding dependencies, working with templates and navigating workspaces and projects.
From a technology perspective the architecture could be described in layers.
What's next for Bootstrap?
Now that the first version is released, the core API is stable and works well. This is why we took our time to get to a release. We can now focus on adding many more plugins, further enhancing the user experience, and offer even more powerful APIs to plugin developers. If you have ideas for plugins, we would be happy to hear; create issues in Jira, or join the mailing list. And even better if you decide to start hacking yourself, Bootstrap is designed for plugin developers after all! Don't hesitate to ask for directions if anything is unclear.
