Hi Eran > On 22 Jun 2017, at 10:01, Eran Twili <eran.tw...@niceactimize.com> wrote: > > 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.
Yes > · 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?) A qualified yes. There is no index of Maven Central (it would be so big and duplicative as to make it unusable). You can configure bnd to create a “view” of bundles from maven central, but this isn’t likely to give you the behaviour that you want (it’s usually used at build time in non-maven workspaces). More useful to you would probably be bnd’s ability to use a POM directly as input to the resolver, but at this point I would still recommend making an index as per the previous step. > · 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. Yes > · It will use the Equinox resolver, so the org.eclipse:osgi jar > should be in the classpath. No. The resolver used will be the resolver included in the bnd plugin, so updating the version of the plugin may change the version of the resolver that is used. The embedded resolver is actually the Apache Felix resolver, which is the resolver used by Equinox, which may be the source of your confusion. > · 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)? You will want to ensure that you configure the export plugin to gather your bundles (rather than creating a fat jar), and then put them wherever makes sense for your runtime. You will also want to create a platform definition describing your runtime’s base capabilities (i.e. the packages provided by your Equinox system bundle). There is a tool in bnd for generating this for you, although I haven’t used it. This platform definition will ensure that your bundles are resolved against the real embedded runtime, including any additional packages that you expose. > · Finally, can I use the maven-bundle-plugin to do part (or all) of > the above, instead of the bnd maven plugins? The maven bundle plugin allows you to create bundles (i.e. it is an alternative for the bnd-maven-plugin). It also offers some of the features of the bnd-baseline-maven-plugin. To my knowledge it does not support any of the indexer/resolver/export plugin features. If you choose to use the maven-bundle-plugin to generate your bundles then you can still use the other plugins to assemble your runtime (i.e. they’re all just OSGi bundles in the end). Regards, Tim > > > 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 > <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 > <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 > <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 <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
