Package versioning allows you to do semantic versioning, when you use the
bundle version as package you’re just wasting manpower and CPU cycles since
there is no benefit.
In OSGi, semantic versioning is a powerful tool because it allows you to
significantly minimize the amount of work you have to do for minor changes. In
contrast with maven, the OSGi package model with semantic version does not
require changes in the metadata whenever there is a small change in a
dependency because the semantic version signals if that change is compatible or
not.
If you version all packages with a bundle version you are not telling anything
about those packages compatibility anymore. If you want to signal anything, you
should at least take the maximum change of any of its constituent packages. So
now whenever you make a major change for one package, all packages are major
changed.
Then again, if you use maven it is already impossible to take the benefits of
semantic versioning during development time because maven creates a rigid hard
coded graph. I.e. if a dependency changes, however minor, all upstream
dependees must adjust their pom. That is partly why releasing on maven is so
hard, you need to change all metadata when you go from snapshot to release.
So it all depends. If you have a single build and all gets build together, who
cares about package versions? Only if you share binaries with others are
package versions important. However, there is more than just package versions,
you also have to follow the architectural rules.
Semantic versioning in OSGi shines if you follow the best practice in software
engineering. You use small cohesive bundles that are coupled via services.
Since services have a well defined contract you can then semantically version
the contract. The advantages of this model are tremendous but you need to have
experienced it to believe it :-(
That said, I know how hard it is to achieve that level in most software
organizations. Codebases are more often than not highly coupled monsters.
Management rarely understands what causes the costs. And developers usually
prefer to spend umpteen hours to prevent getting a budget for doing it right.
So, best of luck! :-)
Kind regards,
Peter Kriens
> On 6 aug. 2015, at 21:16, Endo Alejandro <alejandro.e...@grassvalley.com>
> wrote:
>
> Hello,
>
> I understand all the disadvantages of using require-bundle over
> import-package, but I’m not sure what’s the effect of using the bundle
> version as exported package version, at least by default (i.e. when need it,
> we can create the “packageinfo” file manually to control the package version
> by hand). I am having a hard time enforcing the usage of packageinfo files in
> my team. I created a packageinfo file for every exported package but whenever
> we create new packages we forget to create the file or, what’s worse, when
> modifying code we forget to bump the package version; so we might end up with
> problems where a bundle with a bugfix ends up exporting a package with the
> same version as the buggy package so the fix might or might not work in some
> systems. Would it be acceptable to, by default, version packages with the
> bundle version? This is what the maven-bundle-plugin does when there’s no
> packageinfo anyway. Also, the bundle version is much more visible since we
> use maven and the maven-release-plugin, which bumps the bundle version itself
> so we are sure two released bundles will never have the same version
> therefore neither would the packages.
>
> This sounds better than using Require-bundle since we can still for example
> refactor a bundle without redeploying the consumers. But is it still ok? One
> drawback I see is complexifying (i.e. slowing down) wiring/start-up due to
> the (unnecessary) number of exporters of packages that might actually contain
> the same code.
>
> We are using the maven-bundle-plugin. For now bndtools is not an option.
> Ultimately what I think is the best solution is to start using the baselining
> feature of bnd, but until then, is versioning all packages in a bundle with
> the bundle-version problematic??
>
>
> Thanks for any insight,
>
> Alejandro
>
>
> DISCLAIMER: Privileged and/or Confidential information may be contained in
> this message. If you are not the addressee of this message, you may not copy,
> use or deliver this message to anyone. In such event, you should destroy the
> message and kindly notify the sender by reply e-mail. It is understood that
> opinions or conclusions that do not relate to the official business of the
> company are neither given nor endorsed by the company. Thank You.
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
