Thank you very much Peter and Tim, I’m sincerely grateful. I know that automatic bundle generation from non-modular third party libraries isn’t recommended and I assume I’ll find bundles of my 3rd parties in public repositories. For any exceptional, I know my options (embed, delegate, wrap). That isn’t my concern.
Indeed, we do want to keep working with maven, and prefer not to use additional tools, if possible. If I understood you correctly, the entire OBR process can be manipulated with just bnd maven plugins and a bndrun file. To make sure I got the point: · I can use the indexer plugin to create indexes for my own repositories, so that they will be OBR compatible. · I can then configure to use them, plus public repositories, in my OBR process. (You mentioned maven central. Is it managing an index and can be used by OBR?) · I can then use the resolver plugin with a bndrun file that will trigger the process of retrieving missing bundles (plus transitive dependencies) from the repositories and will resolve my environment. · It will use the Equinox resolver, so the org.eclipse:osgi jar should be in the classpath. · Does the fact that we embed OSGi inside wider (parent) application, and so we lunch the OSGi FW programmatically (via EclipseStarter.startup), change anything regarding the correctness of this approach (since here we’re launching the FW differently, via bndrun)? · Finally, can I use the maven-bundle-plugin to do part (or all) of the above, instead of the bnd maven plugins? Thanks a lot! Eran From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org] On Behalf Of Timothy Ward Sent: Wednesday, June 21, 2017 5:22 PM To: OSGi Developer Mail List <osgi-dev@mail.osgi.org> Subject: Re: [osgi-dev] Help With OBR For reference, the maven plugins to help with this are: * The bnd-indexer-maven-plugin - used to create standard, portable XML repository indexes for a set of POM dependencies * The bnd-resolver-maven-plugin - used to convert a set of run requirements into a list of bundles to use at runtime, uses one or more repository indexes * The bnd-export-maven-plugin - used to create a runnable jar containing an OSGi framework and a list of bundles to install and start. Documentation about these plugins is available at https://github.com/bndtools/bnd/tree/master/maven Regards, Tim On 21 Jun 2017, at 14:43, Peter Kriens <peter.kri...@aqute.biz<mailto:peter.kri...@aqute.biz>> wrote: 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<mailto: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 _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org<mailto:osgi-dev@mail.osgi.org> https://mail.osgi.org/mailman/listinfo/osgi-dev 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 https://mail.osgi.org/mailman/listinfo/osgi-dev
