This website and its associated repositories, are deprecated and no longer supported by the OSGi Alliance. Please visit https://enroute.osgi.org for the latest supported version of OSGi enRoute.
This enRoute v2 archive site is kept for those who do not intend to use the latest version of OSGi enRoute. If you are new to OSGi enRoute, then please start with the latest OSGi enRoute.
A common recurring theme on the Bndtools and OSGi enRoute mailing lists is that people, usually from the Maven world, hate the bnd workspace model. The fact that there is a
cnf directory (like the
.git directory in Git) and that the project directories must be on the same level as the
cnf directory is seen as an (often HUGE) constraint.
The reason that bnd works this way is mostly driven by the simplicity of the model:
cnfdirectory playes the same role as the
.gitdirectory in Git. It marks the workspace as a bnd workspace and contains shared configuration information. In the Maven world, this role is often played by the parent POM in a multi-module setup.
Simplicity pays off in many different places.
In the Maven world every project is stand-alone and coupled via the groupId/artifactId/version coordinates that each stand-alone project has. All interaction goes indrectly through the .m2 repository. However, in practice many projects are quite close together and share common information. That is why in the Maven world real world projects often use the