I'm a little concerned about positioning deployer function below file
install.
There are clearly many single bundle application scenarios where this
makes a lot of sense. But if you consider applications consisting of
multiple bundles where the deployer needs to perform certain
operations on the whole set of bundles, things get a bit tricky since
the result of that install operation is presumably limited to be a
single Bundle.
Also isn't it likely that the Karaf deployer will evolve at a faster
rate than the Felix OSGi framework and possibly even spawn multiple
variants?
So should the Karaf deployer should be integrated tightly in to file
install or enabled to plug in via an extension mechanism so that it
can logically sit on top of file install and perhaps more easily cope
with multiple bundle operations and evolve faster?
Glyn
On 15 Jun 2009, at 15:31, Richard S. Hall wrote:
I think this sounds reasonable as long as it keeps the basic simple
functionality in tact by default and the implementation remains
simple overall, since that was the original goal, as mentioned by
Sahoo and Filippo.
It doesn't sound like the added features add too much complexity and
could also be made optional where appropriate. So, that sounds good.
The original idea for FELIX-922 (supporting different types of
files) was to create something really lightweight, such as a simple
handler service interface which the core could retrieve from the
service registry and other bundles could implement. It sounds like
this is what has been done, so that seems good too.
Also as mentioned, merging might be more difficult, since the code
bases have changed, but merging features sounds possible.
I had also wondered about supporting start levels. My original
thought there was to create numbered subdirectories that correspond
to the start level for the contained bundles; however, that might be
problematic with exploded bundle support...something to think about.
-> richard
On 6/15/09 4:45 AM, Guillaume Nodet wrote:
I'd like to start discussing how we can merge karaf deployer and
felix
fileinstall.
Note that karaf deployer is originally based on the same code base
but
has since evolved.
Here are a list of the main features we've added to the karaf
deployer
over time:
* use the preference service (if available) to store the status
of
the deployer
thus the last update time for each tracked object is stored
and
at restart the deployer
is able to detect changed files
* ability to handle exploded bundles
* ability to transform artifacts on the fly (wars, spring config
files, blueprint config files, etc...) through OSGi services
this issue has been raised in FELIX-922
I know some of you wants to keep file install minimalistic, so I'd be
fine keeping both versions around if that's the outcome of the
discussion, but I think we need to have this discussion at some
point.
Note that the karaf deployer is only 35k whereas fileinstall is 32k
... so I guess we need to define what minimalistic / lightweight /
(whatever adjective you want) is ...
