On Tue, Aug 26, 2008 at 9:16 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > ...I am against this move for now for the following reasons: We also still > have > the jcrinstall bundle in the whiteboard. Before doing anything at all, it > has to be decided how to merge these two together again...
Ok, I suggest starting with a list of requirements for such a module, and we can then see which of the jcrinstall and jcrbundles modules are better suited, or what to take from where. In the list below, "OSGi file", for lack of a better name, refers to a bundle (.jar) file, a deployment package (.dp) file, or a config (.cfg) file. "JCR installer" is the module that we want to create out of the current jcrbundles and jcrinstall code. ** JCR Installer requirements ** 1) OSGi files (nt:file) found in folders (nt:folder) called "bundles" in the repository are installed automatically by the JCR installer. 2) The JCR installer looks for such "bundles" folders under a configurable list of root paths, and uses JCR observation to detect changes. 3) "bundles" folders created when the JCR installer is already running are detected and activated automatically 4) The order in which OSGi files are found into the repository does not matter, the JCR installer maintains a list of pending items that must be installed. 5) Removing an OSGi file from the repository causes the corresponding OSGi item to be removed from the framework. 6) The removal of an OSGi file while the JCR installer is not running is detected when the JCR installer restarts 7) State information, where necessary (for example for requirement 6) is stored independently for each Sling instance Do people have additional requirements? ** jcrbundles status ** In revision 689009, I think jcrbundles supports all of the above, with the following limitations: -Requirement 7) is not fulfilled, as jcrbundles stores state information in repository nodes under a fixed path, which would be a problem if several Sling instances share the same repository. -jcrbundles does not currently support deployment packages, but that shouldn't be hard to add. -jcrbundles does not maintain a queue for configs that are to be installed, the queue is only used for bundles. It should be generalized to be usable for bundles, deployment packages and configs > -...In addition, IIRC, we once discussed an idea to contribute the JCR based > installer to the Apache Felix project and explore how the JCR Install (or > however we may finally call it) might be merged with the Apache Felix > Fileinstall bundle.... The easiest might be to factor out the common OSGi-related operations, and let each implementation (fileinstall, jcrinstall, etc.) handle the rest. But we can look at that once we have decided on which implementation we keep. -Bertrand
