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 ...
