1) How does bnd figure out the versions
If you do not specify a version in the bnd file, bnd looks in the manifest of
the bundle providing the package, then in a file called packageinfo that is a
resource in the package, and if that fails it looks for a Version annotation in
the package-info.class.
2) Automation
I see it as a two pronged approach. Whenever you make a change to an exported
package you should update the packageinfo file. This is really close to the
code you changed and it should absolutely be connected to a commit message in
your source control system. Second phase is when you submit your artifact to a
repository. At that moment, you replace an existing "current" version and then
it is possible to compare the packages in the old and new versions and check
that they follow the rules wrt versioning.
bndtools currently has a GUI for this from CommActivity but the plan is to move
that code to bnd so that the check can also be done from maven, ant, etc.
Maven is not a dirty word around here. It is a very widely used build system
and I go to great lengths to support it with bnd. It is not my build system but
it shares that position with the majority of build systems. We work very hard
in bndtools to do the core functionality in bnd so that it is available in
maven and only focus on the GUI in bndtools.
3) bndtools
As said, we have a very interesting function to release an artifact to a
repository while checking the delta for consistency. I think bndtools is a
really interesting development but we need more funding to increase the
development speed, it is really hard to do this kind of major project on the
side :-( on top of busy jobs.
However, there are already very interesting features in bndtools and more
coming. I am currently working with a student to develop a program that will
allow you to refactor a large non-osgi project in bundles.
Kind regards,
Peter Kriens
On 1 aug 2011, at 00:46, Lindsay Smith wrote:
> Hi all,
>
> I've got some questions about development lifecycle of OSGI components, and
> specifically maintaining and using package versioning correctly. All the
> rationale behind having package versioning is sound in my opinion, OSGI has
> the right abstraction. In my experience the hard part really is how this is
> realised through day to day development practices.
>
> I architected the transition of our middleware product from a 'standard' Java
> application to an OSGI-architected one. The main driver for us was the class
> isolation that OSGI can provide - and this was most important for us not for
> our own components, but for classes that are defined by end users of the
> platform. The transition was on the whole very positive, our architecture
> is much more solid I think, and the build process went from a monolithic
> build to many individual components.
>
> Since time was tight we never introduced packaging versioning, and never
> have. We still rely on 'naïve' jar versioning, and manually manage package
> level issues as they arise. I suspect that many OSGI systems are the same.
>
> I'm attracted to having proper package versioning on our components, but
> frankly I can't work out how to integrate it into our development process.
> Put simply, if you have to maintain the package versioning manually, it's
> never going to work. Unless tools can automate the package versions (at
> least at the export side), I don't think the cost will ever outweigh the
> benefit. I feel that this points to the heart of the 'complexity' argument
> that detractors of OSGI make - while the model is sound, unless the model is
> inherent at every level of development and deployment then it cannot be
> adopted without introducing the need for 'expert' (in that it's not common)
> knowledge about OSGI into the development cycle.
>
> Anyway, I have some questions about package versioning which I hope can
> enlighten me and help me towards some kind of solution path.
>
> The Bnd tool is the canonical tool for managing package versions in the
> manifest. I'm interested to know - how does it work out imported package
> versions? Does it directly read the manifest of the bundles referenced by
> your bundle?
>
> What tools are there for maintaining your package versions? Is there a tool
> that I can use to detect API changes between two versions of a bundle? For
> such a tool to work, you need something to compare it to - so what's the
> standard for the 'last thing to compare to'? The last released version? The
> last built version? This part is crucial - it seems to me you need a build
> system that can go and find the last released version all by itself (maven
> style, although my impression is that that's a dirty word around here) and
> fail if your package versions have not been set correctly. Using the last
> released version makes sense to me since that's all that really matters -
> steps of interim changes are irrelevant.
>
> I am aware of the bndtools project - and this shows some real promise as an
> alternate, lightweight set of tools for managing bundle development. I
> haven't found it useful yet, it's still under development and I'm not sure
> that our workflow fits into its model, but I check on it all the time for
> progress. More docs would be great.
>
> Thanks in advance
>
> Lindsay
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
