That's an interesting perspective.
I was considering the choice of using Require-Bundle versus using
Import-Package, more in the context of allowing the provider to
rearrange packages in different bundles, across time. Not in the context
of versioning.
thanks
erwin
Op 10/08/2015 om 11:14 schreef Peter Kriens:
What value does the consumer have when the provider ignores semantic
versioning? You might then (accidentally) resolve but what would it
mean? If you repeat this over a large number of bundles you just
created a lot of work without any benefit.
If the provider does not use package exports, it is easier to use
Require-Bundle because the package versions are then just busy work imho.
Therefore, in my world it be a deterioration if we made the bundle
version the default (I think this was a very bad decision in the
bundle plugin). You would imply some semantics that actually do not
exist. Again, if you have a single build that creates all artifacts
then your model works, but having no package versions would also work
just as well.
But don’t let me stop you, bnd supports what you want:
Bundle-Version: 4.1
-includeresource: classes
-exportcontents: *;version=${Bundle-Version}
Kind regards,
Peter Kriens
On 10 aug. 2015, at 10:53, erwindl0 <erwin...@gmail.com
<mailto:erwin...@gmail.com>> wrote:
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 <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