It seems relatively pointless, though, if we go with the other
mechanism, since you can easily add the functionality without adding it
to the core directly, which is the whole point.
We apparently need the extensibility functionality to merge with Karaf's
branch of File Install and we had contemplated such extensibility even
before that, so I would be against direct support in the core.
In reality, all artifact processors should be converted to this "new"
extensibility service, then the debate is purely about which
implementations are included in the core and which have to be installed
separately.
-> richard
On 6/24/09 11:39 AM, Alin Dreghiciu wrote:
Well, we are talking about pretty much a small change as it only adds the
code to read the content of the link file and instead of a file input stream
it uses url.openStream. So, it does not introduce any new dependency and the
changes are relative small in
size. I can out up a patch quickly. It may look like a lot of changes
but is just moving code around.
On Wed, Jun 24, 2009 at 4:39 PM, Richard S. Hall<[email protected]>wrote:
On 6/24/09 8:52 AM, Filippo Diotalevi wrote:
On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciu<[email protected]>
wrote:
Hi guys,
Yesterday I got the question if Pax URLs are supported by FileInstall. Of
course there are not as you must have the bundle in the scanned
directory.
But, In my view with quite a simple change this can be done. And is about
making FileInstall support any url, so including pax urls.
The idea is that file install to support beside jar, .cfg files also .lnk
files. What is a link file? A simple text file that contains the url of
the
actual bundle to be installed.
So, if file install finds such a file, it reads the content and installs
the
bundle mentioned in the file via url. If .lnk file changes the old
content
(bundle) is uninstalled and the new one is installed.
To me looks like a powerful option. A more "advanced" usage would be that
teh .lnk file to be a properties file with properties as "url" and
"start"
and "startlevel".
Hi Alin,
as discussed at [1], I think that there is definitely interest for
extending FI to support other artifacts besides jar and cfg files.
On the other side, I'm also of the opinion that FI should be usable
with the minimum felix configuration (felix+shell+fileinstall), with
no additional dependencies.
I think the technical solution to make everybody happy should be the
same adopted by the Apache Karaf Deployer ([2]): keep the fileinstall
lightweight, supporting only jar and cfg, and use the whiteboard
pattern to allow the definition of additional "deployers".
Doing this way, FI would remain clean and lightweight, and you will be
able to install new bundles adding additional support for other
artifacts (.lnk, .war, karaf features and so on)
WDYT?
I agree.
-> richard
[1]
http://www.nabble.com/-DISCUSS--Align-Karaf-deployer-and-felix-fileinstall-td24030876.html#a24032869
[2]
http://svn.apache.org/repos/asf/felix/trunk/karaf/deployer/filemonitor/src/main/java/org/apache/felix/karaf/deployer/filemonitor/DeploymentListener.java
