You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Alin Dreghiciu <ad...@gmail.com> on 2009/06/24 14:32:11 UTC
New feature in FileInstall
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".
I can do this but my question is if it worth doing it as you may not find it
useful and there will be a patch that may not be just a simple
change as I looked at what has to be changed.
--
Alin Dreghiciu
Software Developer - Looking for new projects!
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
Re: New feature in FileInstall
Posted by Toni Menzel <to...@okidokiteam.com>.
If someone needs votes for doing this effectively, here's my +1
On Wed, Jun 24, 2009 at 5:39 PM, Alin Dreghiciu <ad...@gmail.com>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 <heavy@ungoverned.org
> >wrote:
>
> > On 6/24/09 8:52 AM, Filippo Diotalevi wrote:
> >
> >> On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciu<ad...@gmail.com>
> >> 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
> >>
> >>
> >
>
>
> --
> Alin Dreghiciu
> Software Developer - Looking for new projects!
> My profile: http://www.linkedin.com/in/alindreghiciu
> My blog: http://adreghiciu.blogspot.com
> http://www.ops4j.org - New Energy for OSS Communities - Open Participation
> Software.
> http://www.qi4j.org - New Energy for Java - Domain Driven Development.
>
--
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
toni@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
Re: New feature in FileInstall
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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<he...@ungoverned.org>wrote:
>
>
>> On 6/24/09 8:52 AM, Filippo Diotalevi wrote:
>>
>>
>>> On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciu<ad...@gmail.com>
>>> 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
>>>
>>>
>>>
>
>
>
Re: New feature in FileInstall
Posted by Alin Dreghiciu <ad...@gmail.com>.
Use case: As it allows any url
I can just have links to build files via file: protocol and then when
I want to update a file I just do a "touch".Plus, imagine
the "power" of installing pax urls together with file install. I can have
.lnk file doing war transformation, automatic wrapping, mvn references.
And the change is so trivial and small... ;)
On Wed, Jun 24, 2009 at 8:30 PM, Filippo Diotalevi <
filippo.diotalevi@gmail.com> wrote:
> On Wed, Jun 24, 2009 at 5:39 PM, Alin Dreghiciu<ad...@gmail.com>
> 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.
>
> I see. Having used Pax-Url I thought you wanted to add support for
> custom protocol like mvn: or wrap:, which would require additional
> code or dependencies.
>
> Anyway, what would be the expected use case for .lnk files?
> I mean, fileinstall usually update a bundle/file when it finds a new
> version of it in the watched directory. What do you expect with .lnk
> files?
> In other words, is the (linked) bundle updated when
> a) the .lnk file is modified
> b) when the resource pointed by the .lnk file is modified
> ?
> --
> Filippo Diotalevi
>
--
Alin Dreghiciu
Software Developer - Looking for new projects!
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
Re: New feature in FileInstall
Posted by Alin Dreghiciu <ad...@gmail.com>.
My intention was to update only when the link file is updated.
On Wed, Jun 24, 2009 at 8:30 PM, Filippo Diotalevi <
filippo.diotalevi@gmail.com> wrote:
> On Wed, Jun 24, 2009 at 5:39 PM, Alin Dreghiciu<ad...@gmail.com>
> 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.
>
> I see. Having used Pax-Url I thought you wanted to add support for
> custom protocol like mvn: or wrap:, which would require additional
> code or dependencies.
>
> Anyway, what would be the expected use case for .lnk files?
> I mean, fileinstall usually update a bundle/file when it finds a new
> version of it in the watched directory. What do you expect with .lnk
> files?
> In other words, is the (linked) bundle updated when
> a) the .lnk file is modified
> b) when the resource pointed by the .lnk file is modified
> ?
> --
> Filippo Diotalevi
>
--
Alin Dreghiciu
Software Developer - Looking for new projects!
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
Re: New feature in FileInstall
Posted by Filippo Diotalevi <fi...@gmail.com>.
On Wed, Jun 24, 2009 at 5:39 PM, Alin Dreghiciu<ad...@gmail.com> 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.
I see. Having used Pax-Url I thought you wanted to add support for
custom protocol like mvn: or wrap:, which would require additional
code or dependencies.
Anyway, what would be the expected use case for .lnk files?
I mean, fileinstall usually update a bundle/file when it finds a new
version of it in the watched directory. What do you expect with .lnk
files?
In other words, is the (linked) bundle updated when
a) the .lnk file is modified
b) when the resource pointed by the .lnk file is modified
?
--
Filippo Diotalevi
Re: New feature in FileInstall
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/6/24 Dennis Geurts <de...@luminis.nl>
> Hi alin,
>
> Just my 2cents...
>
> I seem to recall that the .lnk extension under windows is used to define
> shortcuts.
>
> Does this potentionally impose problems for the windows users out
> there??
>
Tried locally and Windows lets me create arbitrary ".lnk" files.
Of course double-clicking on them has no effect but I couldn't see any
problem apart from that.
We could always use ".link" if it turned out to be an issue... but I've seen
other apps use ".lnk".
If people find this useful then I don't see any major reason not to add it
to the core - as it's not
really a major piece of code (just: open the file => take the string => new
URL => openStream)
it doesn't add any extra dependencies. Just be careful of circular links :)
Otherwise guess it could be an extension - any idea when whiteboard support
will be available?
Cheers, Dennis
>
>
> On 24 jun 2009, at 17:41, "Alin Dreghiciu" <ad...@gmail.com> 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
> > <he...@ungoverned.org>wrote:
> >
> >> On 6/24/09 8:52 AM, Filippo Diotalevi wrote:
> >>
> >>> On Wed, Jun 24, 2009 at 2:32 PM, Alin
> >>> Dreghiciu<ad...@gmail.com>
> >>> 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
> >>>
> >>>
> >>
> >
> >
> > --
> > Alin Dreghiciu
> > Software Developer - Looking for new projects!
> > My profile: http://www.linkedin.com/in/alindreghiciu
> > My blog: http://adreghiciu.blogspot.com
> > http://www.ops4j.org - New Energy for OSS Communities - Open
> > Participation
> > Software.
> > http://www.qi4j.org - New Energy for Java - Domain Driven Development.
>
--
Cheers, Stuart
Re: New feature in FileInstall
Posted by Dennis Geurts <de...@luminis.nl>.
Hi alin,
Just my 2cents...
I seem to recall that the .lnk extension under windows is used to define
shortcuts.
Does this potentionally impose problems for the windows users out
there??
Cheers, Dennis
On 24 jun 2009, at 17:41, "Alin Dreghiciu" <ad...@gmail.com> 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
> <he...@ungoverned.org>wrote:
>
>> On 6/24/09 8:52 AM, Filippo Diotalevi wrote:
>>
>>> On Wed, Jun 24, 2009 at 2:32 PM, Alin
>>> Dreghiciu<ad...@gmail.com>
>>> 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
>>>
>>>
>>
>
>
> --
> Alin Dreghiciu
> Software Developer - Looking for new projects!
> My profile: http://www.linkedin.com/in/alindreghiciu
> My blog: http://adreghiciu.blogspot.com
> http://www.ops4j.org - New Energy for OSS Communities - Open
> Participation
> Software.
> http://www.qi4j.org - New Energy for Java - Domain Driven Development.
Re: New feature in FileInstall
Posted by Alin Dreghiciu <ad...@gmail.com>.
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 <he...@ungoverned.org>wrote:
> On 6/24/09 8:52 AM, Filippo Diotalevi wrote:
>
>> On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciu<ad...@gmail.com>
>> 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
>>
>>
>
--
Alin Dreghiciu
Software Developer - Looking for new projects!
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.
Re: New feature in FileInstall
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 6/24/09 8:52 AM, Filippo Diotalevi wrote:
> On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciu<ad...@gmail.com> 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
>
Re: New feature in FileInstall
Posted by Filippo Diotalevi <fi...@gmail.com>.
On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciu<ad...@gmail.com> 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?
[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
--
Filippo Diotalevi