Installable Units in Ace

[Toni Menzel <to...@okidokiteam.com>]

Is there in ace already a concept of "installable units" (p2 terminology) ?
Speaking of the fact that, if i make a group and assign it to a certain
gateway (through license), does the server know about the gateways
capabilities so it can make sure things are resolving ?

To me this would be a crucial concept, not because its coming from p2 but to
at all allow to automatically resolve dependencies for a group. (for
example).

Sure, because every gateway can be different, it is hard to manage this if
features are assembled on the server (web ui: clicking the triangle bundle)
and not on the gateway.

Any thoughts already in this direction ?

-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
toni@okidokiteam.com
http://www.ops4j.org     - New Energy for OSS Communities - Open
Participation Software.

Re: Installable Units in Ace

[Marcel Offermans <ma...@luminis.nl>]

Hello Toni,

On Oct 7, 2009, at 10:32 , Toni Menzel wrote:

> Is there in ace already a concept of "installable units" (p2  
> terminology) ?

There probably isn't a direct equivalent of that, but both groups and  
licenses could be seen as IU's (reading the definition at http://wiki.eclipse.org/Installable_Units 
).

> Speaking of the fact that, if i make a group and assign it to a  
> certain
> gateway (through license), does the server know about the gateways
> capabilities so it can make sure things are resolving ?

Currently we do not have any requirements and capabilities yet (like  
IU's and also OBR specifies). If you look at the entities in the  
repository though (component/bundle, group, license, target) they do  
have ways of adding your own properties and those can be used for  
resolving constraints. Also, if you look at the way we specify  
associations between these entities, an association has a left an  
right hand side. Each of these can be expressed as an LDAP query. Our  
current UI creates them as (name=mybundle-1.0.0.jar) so the  
association becomes a 1:1 association, but you can programmatically  
also do stuff like creating associations that match more entities,  
using something like (&(execution-env=java6)(category=core)).

> To me this would be a crucial concept, not because its coming from  
> p2 but to
> at all allow to automatically resolve dependencies for a group. (for
> example).

I have mixed feelings about this.

On the one hand, resolving package dependencies definitely helps. You  
can make sure at least everything resolves and starts. Same goes for  
matching things like execution environment.

On the other hand...

One of the most important mechanisms in OSGi is the use of services  
and those in general do not have any such metadata. Of course you  
could parse XML files of Declarative Services and other similar  
models, but there is no system in general to describe services in  
terms of metadata. So at this level you cannot "resolve" services very  
well.

I'm not a big fan of developers just selecting components and "seeing  
what the cat drags in". For any application there should be a well  
thought out design and a concious decision about what components and  
dependencies to use and not to use. From this design you should be  
able to directly "import" things like groups and licenses (or  
installable units in p2 for that matter).

> Sure, because every gateway can be different, it is hard to manage  
> this if
> features are assembled on the server (web ui: clicking the triangle  
> bundle)
> and not on the gateway.

That exactly is the problem. Every gateway can be different and those  
differences come from:
a) different framework implementations and launchers which export  
things through the system bundle, support certain execution  
environments, etc.
b) different bundles that might have already been installed outside of  
the scope of the management agent
c) differences in actual wiring that can even occur if you install the  
same set of bundles in a different order (especially if you do not  
refresh everything)

One way to resolve this is to have the exact same resolver that your  
framework would have and use that on the server. Such a resolver would  
have to have either a current "snapshot" of the actual wiring and  
installed set of bundles, or some feature for replaying all life cycle  
changes in history (probably that's a lot of work if you have hundreds  
of updates over time).

> Any thoughts already in this direction ?

One way to really test if some combination of groups and licenses will  
work is to just deploy it to a test framework. So my advice in general  
would be to setup a way of working where any new software or versions  
of components are first deployed to a testing/staging environment  
where they are not only installed, but where actual integration /  
system / performance tests are deployed to really validate if  
everything works correctly. Only after passing that stage can you mark  
a certain set of components as "tested" or "stable" and roll them out  
to production targets.

Greetings, Marcel