felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulo Renato de Athaydes <renatoathay...@hotmail.com>
Subject RE: Bundle dependency management
Date Fri, 12 Dec 2014 20:05:49 GMT
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: benson@basistech.com
> To: users@felix.apache.org
> 
> On Fri, Dec 12, 2014 at 4:58 AM, Robert Munteanu <rombert@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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
 		 	   		  
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message