felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim McIver <tmci...@verizon.net>
Subject Re: Automatically update bundles
Date Tue, 05 Aug 2014 19:23:29 GMT
Thanks.  I'm aware of the existence of DeploymentAdmin but don't know
much about it.  Will it update an existing bundle from a repository?

I've looked a bit at Apache Ace.  But it seems to depend on being aware
of the 'targets' that it updates.  This is not possible for me.  I need
to update bundles in a 'pull' fashion.


On 08/05/2014 06:44 AM, Jan Willem Janssen wrote:
> On 04/08/14 17:34, Tim McIver wrote:
> > I've got an application that is using Felix in an embedded fashion
> > and we're using OSGi to implement a plugin architecture.  One of my
> > main goals is to automatically update any installed plugins from an
> > external OBR.  Before I spend any more time trying to write custom
> > code to do this, I'd like to know if there is an existing feature
> > in OSGi or Felix that does this already?  I've begun writing code
> > that gets the symbolic name of any installed plugin, then uses this
> > to get all Resources with a given symbolic name from the external
> > OBR.  Next, I would see if any of these Resources are a more recent
> > version of what's installed.  Finally, I need the framework to use
> > these newer bundles instead of the old ones.  I feel like this is a
> > common use case but it's unclear to me if this is already
> > implemented in OSGi, Felix or some other framework.
> You probably want to take a look at the Deployment Admin specification
> (also present as Felix subproject), which allows you to define
> "deployment packages" containing new bundles and/or other resources to
> install/update.
> What Deployment Admin does not provide, is an easy way of determining
> what should go into a deployment package. If your plugins are fully
> self-contained, this might be as easy as pie, but if your plugins
> consist of multiple bundles and/or resources this might become rather
> difficult. In these cases, it might be worthwhile to look into a
> project like Apache ACE for a more complete solution.
> HtH,
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message