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> 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 > 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