Hi Peter,
Thank you for your detailed reply. I also feel the OSGi versioning
approach is stronger than e.g. the maven approach.
Maven is all about their "artifacts" (jars), and when combining this
with their snapshot/release and their pom/parent-pom systems, ends up
being very limiting and complex.
On the other hand, if for whatever reason an Export-Package does not
specify a version, the current default behaviour seems to consider this
as a "0.0.0"/unspecified.
So an Import-Package statement can not set a version either, or it won't
resolve.
Which means that when the provider is not sufficiently strict in its
manifest, the consumer side is also forced to forget about versioning
constraints...
Wouldn't it be an improvement to use the bundle version as "default"
value for exported packages with unspecified versions?
That would still allow the conscious people to follow all good practices
completely, while also easying the entry from more "maven-based"
thinking into the world of OSGI ;-)
I.e. they could already start working with clear dependency mgmt,
Import-Packages with versions etc.
kind regards
erwin
Op 07/08/2015 om 15:12 schreef Peter Kriens:
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
<mailto: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 <mailto: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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
