Guillaume Nodet wrote:
On Mon, Jun 15, 2009 at 11:00, Sahoo<[email protected]> wrote:
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.

FileInstall code has evolved as well, so merge will be painful.
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

file install uses bundle.getLastModified and compares it with
file.lastModified() to detect updates. What's wrong with this approach?

How can fileinstall discover bundles deleted while fileinstall is not
running (usually because the osgi framework has been stopped and
restarted later) ?


Upon restart, it detects that set of bundles installed is more than what's there in watched directory and uninstalls them. At least, that's how it tries to handle the situation.
      is able to detect changed files
  * ability to handle exploded bundles

+1
  * 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


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


While size is important, so are dependencies. We should try not to add too
many dependencies. What are the dependencies of karaf deployer?

There is an additional dependency on the preference service package
(currently not an optional import) and for logging, the dependency is
on org.apache.commons.logging instead of the osgi log service.
We should try to make all these optional dependencies if we decide to merge.

Thanks,
Sahoo

Reply via email to