On Fri, Dec 12, 2014 at 4:58 AM, Robert Munteanu <[email protected]> wrote: > https://ops4j1.jira.com/wiki/display/paxrunner/Pax+Runner
One idea I think I'm learning from all this is that a typical process is to preload an OSGi container and deliver it. I've been thinking in terms of delivering a pile of bundles and loading them up on the fly. I see how Pax+Runner fits in here. It is unfortunate that https://ops4j1.jira.com/wiki/display/paxrunner/Provision+bundles+from+a+Maven+POM+file is an empty page (along with a bunch of other pages.) I also want to return to the original schema I had for a Maven plugin in the context of what I've learned from all of you. In general, there is no global resource of OBR metadata. Given an arbitrary bundle with arbitrary imports, there's no simple way to locating bundles 'in the wide world', let alone select between them, that satisfy the imports. However, in a constrained environment, with (for example) Nexus, you could imagine having enough ORB metadata to fulfill dependencies. It looks as if pax-runner can, in that circumstance, do the job. But that's a bunch of work to make sure that the 'wide world' things that one needs are locally OBR-indexed. That leaves me with a variation on my original idea, which is a complement to the existing maven-bundle-plugin. The maven-bundle-plugin starts from the thought that all, or pretty nearly all, of the OSGi bundles that you need are, in fact, Maven artifacts. It's core behavior applies bnd to Maven dependencies. I'm imagining, essentially, one more goal: copy-dependent-bundles. The idea of this goal is to circumvent the Maven restriction to one version at a time in the dependency graph. It's not completely general would be helpful in the case where the Maven dependency graph does, in fact, describe the OSGi bundles required. The configuration of this goal would look like dependency:copy: a list of artifactItems, one for each of the bundles that you know that you want. For each one, the plugin would obtain the dependency graph, but not resolve it, thus avoiding the collapse of multiple versions. it would download those dependencies, and then you've got a stack of bundles you can provision into your container. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
