Niclas Hedhman wrote:
...
I assume that Require-Bundle will be "marketed" as a "last resort" or "special
cases", since it doesn't rhyme well with "service replacements" and
"alternative implementations", which I thought was central to OSGi.
That would imply that the Maven plaugin has a mechanism to create the
Require-Bundle entry, but require some form of additional "enable".
Somewhat related to what you are talking about:
Yes, the "alternative implementations" aspect of OSGi complicates
building. It would be convenient if the Import-Package (and possibly the
Bundle-ClassPath) property of the manifest was enough for handling the
dependencies during M2 build. But that would require some kind of
discovery mechanism that finds e.g. the right set of API bundles based
on a set of packages. IIUC, M2 repositories doesn't support such behaviour.
Less convenient but still usefull is to explicitly enumerate the API
bundles with "compile" scope and suitable bundles for testing with
"test" scope in the dependecy section of the POM. I guess we can live
with this in a first version of the M2 OSGi plugin.
At a later stage we need an OSGi aware search service for M2
repositories, that can find bundles based on packages, versions info,
"api only", default implementation and other search criteria.
/Daniel
