One of the things that make modularity provides its benefits is that your
modules are, eh, modules. Sadly, many third party libraries are not modules
because they do not manage their dependencies nor do they provide a clean
minimal API. So I would not get too excited about automatic bundle generation
from non-modular third party libraries. Fortunately, for most problems there
are good solutions available. (Karaf is driving a lot of good work here but
there are also many others pushing good modules.) However, this will require
some manual work if you’re unlucky. If this could be automated we’d all be out
of work … :-)
The Felix resolver is nowadays also used in Equinox. In the bnd project, we
provide a maven plugin that uses bndrun files to steer a resolution. This
resolution checks if a set of bundles is compatible and can drag extra bundles
from a repository. These repositories can be a Maven POM, a P2 (Eclipse) repo,
or an OBR index. There is also a maven plugin that can generate an OBR index
based on maven dependencies.
So the parts are there and just verifying if a set of preselected bundles will
work on a framework is quite straightforward. If you want a more automatic
selection process it will require curating the repositories.
Though maybe the news that there is no magic is a bit disappointing, it does
provide you with a system that catches most problems much earlier than
traditional approaches.
> 1. Do we need to implement anything, or there’re implementations that
> we can use?
For this setup there are bnd plugins that generate the index and that can do
the resloving.
> 2. What is the trigger for this process to start during/instead Maven
> build?
They are plugins part of the maven life cycle
> 3. We use Equinox. Does the resolver is the Equinox resolver? How can I
> activate it in the OBR process?
Equinox uses the Felix resolver nowadays. The bndrun will contain your
specification of the runtime and a plugin will resolve it.
> 4. What are my options for public repositories that contains known 3rd
> parties?
Today most code ends up quickly in maven central. Actually, the maven bnd
plugin is one of the most popular plugins. Most modern code has the OSGi
metadata. However, remember that real models are more than just metadata.
> 5. What happens if the 3rd party I need doesn’t exist in my bundles
> repositories? Does the process fail?
Yes.
> 6. There’s, for example, the Apache Felix OBR. Is it an implementation
> of the repository or the resolver or both?
> 7. Does OBR work fluently, or it has many issues?
I think you find that the most advanced workflow are with the bnd maven
plugins. As I stated, properly setup this can make your product a lot more
reliable and stable. However, there is no magic. You will still be required to
understand the parts.
Kind regards,
Peter Kriens
> On 21 Jun 2017, at 14:18, Eran Twili <eran.tw...@niceactimize.com> wrote:
>
> Hi,
>
> I approach you after spending days of research, resulted in only vague high
> level understating of a solution to our problem.
> In my organization, we’re intending to embed OSGi into our application.
> We’re currently exploring the change that will result from moving to OSGi, in
> aspect of provisioning / building our application.
> Till today, we’re using Maven as our build tool.
> So every developer in the team, in his day-to-day work, can make some changes
> in the code, run maven install, and Maven will take care of pulling in the
> transitive dependencies, compiling and building the target jars.
> Now, moving to OSGi.
> Working the same way won’t be sufficient, as Maven may pull in transitive
> dependencies which aren’t bundles.
> In addition, Maven can successfully compile our project, although some
> Manifest requirements are missing, which means the OSGi FW will not resolve.
> But we do want as much automation of the process as possible, so what do we
> do?
> We want that:
> 1. When building our project, we’ll automatically get bundle versions
> of our 3rd parties, including bundle versions of their transitive
> dependencies, without the need to specify transitive dependencies.
> 2. After build we want to verify that our OSGi FW can be resolved. I.e.
> all bundles can be in ACTIVE state.
>
> I read a lot about it and managed to conclude that what we need is OBR.
> However, although I read a lot about OBR, I can’t get the puzzle fixed.
> I couldn’t find any hands-on tutorial of working with OBR end to end.
> I do understand that the main players in the game are: bundles repositories
> and a resolver.
> I understand that I need to start with my own modules as the initial set of
> bundles and that OBR should then automatically pull my missing dependencies
> from the repositories and resolve the OSGi FW.
> But how exactly to do that?
> 1. Do we need to implement anything, or there’re implementations that
> we can use?
> 2. What is the trigger for this process to start during/instead Maven
> build?
> 3. We use Equinox. Does the resolver is the Equinox resolver? How can I
> activate it in the OBR process?
> 4. What are my options for public repositories that contains known 3rd
> parties?
> 5. What happens if the 3rd party I need doesn’t exist in my bundles
> repositories? Does the process fail?
> 6. There’s, for example, the Apache Felix OBR. Is it an implementation
> of the repository or the resolver or both?
> 7. Does OBR work fluently, or it has many issues?
>
> Any help will be much appreciated
>
>
> Regards,
> Eran
>
>
> Confidentiality: This communication and any attachments are intended for the
> above-named persons only and may be confidential and/or legally privileged.
> Any opinions expressed in this communication are not necessarily those of
> NICE Actimize. If this communication has come to you in error you must take
> no action based on it, nor must you copy or show it to anyone; please
> delete/destroy and inform the sender by e-mail immediately.
> Monitoring: NICE Actimize may monitor incoming and outgoing e-mails.
> Viruses: Although we have taken steps toward ensuring that this e-mail and
> attachments are free from any virus, we advise that in keeping with good
> computing practice the recipient should ensure they are actually virus free.
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
> https://mail.osgi.org/mailman/listinfo/osgi-dev
> <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
