IntelliJ OSGi Tool Wishlist
This page documents the desired features for OSGi support in IntelliJ, divided into "minimal" requirements, and everything else. The minimal requirements represent the smallest set of features which would make the tool viable for real OSGi development.
The tool should be based on bnd. Bnd is a library that can build OSGi projects, generate manifest headers, bundles and much more. Bnd is widely used in all parts of the OSGi ecosystem and has become a de facto build language for bundles (and may be standardised in a future OSGi specification release). Bnd can take care of all the low level details of working with OSGi projects, while Intellij can focus on user friendly tooling. Bndtools is built in the same way, on top of bnd.
The project structure should also be based on bnd defaults. Each module (project in Eclipse terms) contains one or more .bnd files that describe the project, and can generate one or more bundles. The project (workspace in Eclipse term) contains a cnf folder which contains project wide configuration. Keeping this structure will maximize use of the bnd libraries, but also automatically ensures compatibility with bndtools, which is crucial for initial adoption.
Dependency management should be entirely based on bnd. A module can depend on other bundles by adding them to the -buildpath in the bnd file of the module. Bundles are found in bundle repositories (there is a specification for this). Bnd already contains code to list repositories and download bundles to a local cache. Only exported packages in the bundles on the build path should be visible by the module; e.g. code completion should not display private classes, and it should be impossible to compile against private classes.
Modules in Intellij should generate bundles at each compile. A manifest should be generated based on the module’s bnd file, and the jar file should be created. Again, bnd has code to do this, Intellij can hook this up to the compiler. Obviously the process should be fast and only re-generate bundles that are actually changed. A simple example of how this could potentially work is the Gradle integration that Paul recently blogged about: http://paulonjava.blogspot.nl/2013/11/building-bndtools-projects-with-gradle.html
Running applications. Possibly the best feature of Bndtools is running an OSGi application from the IDE and hot bundle replacement in a running framework. To run an application a .bndrun file should be created, which lists the bundles that should be installed in the framework. Every time a new bundle is generated, the running framework should be updated with this new bundle as can be seen in this video: https://vimeo.com/user17212182/review/83374139/1cea4e1d61
Integration testing. Bnd can run integration tests, where junit tests are deployed in an OSGi container, together with the code which it is testing. This should be hooked up with the Intellij test runner.
Resolution. Bndtools can resolve a set of requirements, in terms of the "top" bundles that define an app, and discover the full set of bundles that would enable those bundles to work. The resolution process is implemented in bnd and defined by an OSGi specification. The IDE needs to gather the input and present the output from this process to the user.
Wizards, editors etc. Editors for bnd files, wizards for creating new projects etc. are all nice to haves. Although an IDE can really shine here, these features are far less important than the features listed above. Bnd files are in standard Java Properties file format, so an existing editor for this format will work fine. At the next level, a customized editor including highlighting, completions etc for the predefined property names would be nice.