Eclipse automatically compiles your Java source code whenever you save — this is “The Eclipse Way”. Bndtools goes one step further and automatically assembles your bundles whenever the inputs to it are changed. As a result, your bundles are always up to date with the latest code, and ready to run!
Unlike PDE that require package dependency information to be maintained manually, Bndtools uses bytecode analysis to accurately calculate the dependencies of your OSGi bundles, automatically handling (semantic) versions. Additionally, many OSGi aspects are verified on the fly. With Bndtools, the manifest just works.
Bndtools has extensive support for the OSGi Declarative Services, Manifest, and Metatype annotations. Not only does it automatically build the required XML, it also provides excellent direct feedback when the annotations are used in the wrong way.
Bndtools adds a number of additional decorators and visualizers to Eclipse that are optimized for OSGi. For example, a package shows if it is included and if it is exported. A class is marked if it is an OSGi Component. A special JAR editor provides detailed information into bundles and normal JARS, both graphically and textual. A bnd editor provides graphic & source access to the bnd files. The GUI access to start with, the text editor when your build grows. As they always do. A resolution viewer shows for any selected bundle what its capabilities & requirements are. And more important, which class is the referrer.
Bndtools leverages bnd's extensive knowledge and understanding of the contents of its bundles to produce useful content assists. Bndtools performs complex analysis of a variety of compiler errors that can potentially caused by missing types, looks for bundles that contain those types, and offers them as suggestions to add to your build or test path. It is even able to offer possible solutions to problems that on the surface are not obviously caused by missing types (such as "missing methods" which are actually caused by superclasses not being present on the classpath) that can be hard to debug.
Unlike PDE, bnd stores all build information declaratively, in easy to read plain Java property files called bnd files. These property files are put in an inheritance chain so that there is always one place to define shared information, preventing redundancy. A very powerful macro processor can combine and filter properties so that bug inciting redundancy is further reduced. Hundreds of built-in functions provide very detailed access to the bnd build model, the output JARs, the repositories, environment variables, and can even call system commands.
Bndtools features a pluggable repository model for bundles, that may be referenced at build-time and also used to satisfy runtime dependencies. Repository plug-ins exist for OSGi, P2, and Maven/Nexus.
Bndtools uses the OSGi Resolver to create runtime assemblies, allowing us to concentrate on just the "top-level" bundles that comprise our application. The remaining bundles are resolved from the repositories automatically. No more wasting time trying the right combination by trying.
The instant builder will keep all artifacts build at all times. When you launch an application from Bndtools, it will extend this dynamism to the launched runtime. Any bundle that changes in Eclipse, will be updated in the runtime dynamically. This gives Bndtools a very light weight feeling while still providing all the software engineering from Java.
Besides standard JUnit, Bndtools incorporates an integrated test runner for OSGi that launches an OSGi framework containing an automatic assembly of bundles, executes the test cases declared in those bundles, and shuts down OSGi. The whole process takes mere milliseconds and results are reported in the standard Eclipse JUnit view.
Bndtools, by being based on bnd, can release the workspace in a number of ways:
Releases can happen manually from the IDE or better, they can be automated in the CI build.
Bndtools has a unique feature, not found in any other IDE, that it compares your API code continuously with a previous release according to semantic version rules. The moment you make a change that would not be compatible with the package version, you get an error on both the version and the violating code. For example, if you add a method to an interface, that is in an API package, you immediately see this method marked red.
Every Bndtools workspace automatically includes a Gradle based continuous integration (CI) build. Since the gradle build uses the bnd information, there is no need to learn gradle. The CI build will create identical artifacts at, for example, Github Actions. The CI can release to Maven repositories, create p2 repositories, or anything else you need.
Bndtools uses the bnd workspace concept. Although Bndtools fanatically tries to follow the Eclipse paradigm, always built all artifacts, it wen out of its way to make this fast enough to supports hundreds of projects in a workspace, some companies even have up to a thousand projects in a workspace. To help navigating these workspace, the Bndtools explorer provide a very lightway to quickly filter the projects by name or status. Having all projects for a product a single workspace does wonders for productivity and product quality, experience shows.
Bndtools is a plugin/bundle for Eclipse. This means we inherit all the wonderful tooling from Eclipse. Bndtools goes out of its way to integrate deeply, supporting many extension points. Intellij is supported with the OSMORC plugin, maintained by IDEA.
Bndtools is Open Source Software, distributed under the terms of the Eclipse Public Licence.