Hi,
Vidar Ramdal schrieb:
> On Tue, Nov 17, 2009 at 8:34 AM, Felix Meschberger <fmesc...@gmail.com> wrote:
>
>> [...]
>> If I change the API in the o.a.s.api.resource package, why would it make
>> sense and make lives easier, if I upgrade the minor version number of
>> the package o.a.s.api.request, too ? In fact, this makes life even
>> harder for the end user: We have to upgrade the bundling implementing
>> the request interface (if only to increase package import version) and
>> we have to deploy the new bundle. Why ? Because the resource API was
>> upgraded. Does not make any sense at all. This is not what OSGi is about.
>
> OK, but how often does that happen?
> If a package is developed independently of other packages in the same
> bundle, it sounds to me as if the package should be a bundle of its
> own right?
>
It depends ;-)
Really, this does not happen very often and in fact, we have one bundle
IIRC which is the main "culprit" of this discussion: The Sling API bundle.
All other bundles have rather "complete" exports in that they export API
for implementations contained in the same bundle. And most of these
bundles export a single package anyway, so there is not much of a deal
either -- except that we might want to replace the
"version=${pom.version}" statement by an explicit version number
assignment to prevent export version increase on bundle version increase.
This bundle contains packages which evolve independently of each other
but to make it easier for deployment (and development for that matter)
we merge these packages into a single bundle.
Regards
Felix
