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
