Agreed. It doesn't make sense to merge if they don't fit, but if there
could be some common abstraction of observables that we could easily use
to integrate these two sources and possibly others in the future, then
it would be cool. Different observable implementations could be
delivered as bundles, thus not coupling things together. Sounds cool. ;-)
Even if we decide to keep the completely abstract, it seems like it
might be worthwhile to make their APIs as similar as possible, if not an
abstract API framework that could server as a model for people wanting
to create similar functionality for other sources. If we had all the
time in the world, that is... ;-)
Seriously, though, the closer that we make the code bases, the easier it
will be for us to maintain.
-> richard
Felix Meschberger wrote:
Hi Richard,
Karl already suggested finding out whether the two can be merged. Peter
thought it might not be a good idea to merge due to different couplings
and that they both might live together side-by-side.
If we would merge, we would certainly have to make sure to not create a
mandatory dependency on JCR in case of users just want to use the file
part.
So for a first step, I would think, we could just add both and then in a
second step check it out, whether we can actually merge.
Regards
Felix
Am Donnerstag, den 20.12.2007, 11:10 -0500 schrieb Richard S. Hall:
We are in the process of Peter contributing FileInstall to Felix...still
trying to get the paperwork recorded correctly.
It seems if the two could be merged, it might be worthwhile. However, I
guess that is not a requirement, but it would be nice and would
strengthen the argument for inclusion into Felix.
-> richard
Felix Meschberger wrote:
Hi all,
Inspired by Peter Kriens' FileInstall [1] tool, I created JcrInstall
[2]. This tool works almost exactly as the original FileInstall with the
following differences:
(1) It operates on a JCR repository [3, 4]
(2) It uses JCR Observation instead of polling
(3) It just has a single instance, ergo a single location only
Other than that if works the same:
* Storing JAR files installes contained bundles
* Updating JAR files updates the bundles
* Removing JAR files unsinstalls bundles
* Storing or updated configuration files (extension is ".cfg")
creates or updates ConfigurationAdmin configuration
* Removed configuration files deletes configuration
The full path of JAR files with a prefix of "jcrinstall:" is used as the
Bundle location. The name (without the path and the .cfg extension) of
configuration files is used to designate the configuration PID. The name
is turned into factory and configuration PID in the same way as for
FileInstall.
A discussion on the Sling developers list [5] showed, that it would make
sense to have this in the Felix project because it could benefit the
OSGi community at large and not just the Sling people.
WDYT ?
Regards
Felix
[1] http://www.aqute.biz/Code/FileInstall
[2]
http://svn.apache.org/repos/asf/incubator/sling/whiteboard/jcrinstall
[3] http://www.jcp.org/en/jsr/detail?id=170
[4] http://jackrabbit.apache.org
[5]
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01141.html
