Hi,
I thought you just wanted to easily create a Felix runtime for your OSGi
bundles?
> So, here I am, setting up an application that embeds Felix. I need it
> to contain a certain collection of bundles -- and then some
> dependencies of those bundles.
Using osgi-run, this Gradle script will install 2 different versions of Guava
and run everything with Felix:
build.gradle
######################
buildscript {
repositories {
jcenter()
}
dependencies {
classpath "com.athaydes.gradle.osgi:osgi-run-core:1.1"
}
}
repositories { mavenCentral() }
apply plugin: 'osgi-run'
dependencies { // some examples of bundles
osgiRuntime 'com.google.guava:guava:12.0'
osgiRuntime 'com.google.guava:guava:16.0'
}
########################
The bundles, specified by their artifact coordinates in "osgiRuntime", will be
downloaded from the repositories you configured (Maven or Ivy repos, local
files etc, see
http://www.gradle.org/docs/current/userguide/dependency_management.html#sec:repositories)
and added to the OSGi environment. Notice you can have as many of the same
artifact with different versions as you want.
Sorry if I misunderstand you.
Regards,
Renato
> Date: Fri, 12 Dec 2014 07:44:36 -0500
> Subject: Re: Bundle dependency management
> From: ben...@basistech.com
> To: users@felix.apache.org
>
> On Fri, Dec 12, 2014 at 4:58 AM, Robert Munteanu <romb...@apache.org> 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: users-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
