date:20090624


On 06/24/2009 06:55 PM, Marcel Offermans wrote:


On Jun 23, 2009, at 11:52 , Filippo Diotalevi wrote:


Hi,
 as I was mentioning to some Felix' guys in Zurich, the call for
paper for Devoxx is open at:
http://presentations.devoxx.com/com.javoxx.cfp.CFPMain/CFPMain.html
(firefox only, I guess)

Devoxx will be held in Antwerp, NL, on Nov 16-20th.


Antwerp is in Belgium. :)


Netherlands, Belgium...it's all the same isn't it? ;-)

-> richard




I'm not completely sure it is possible to submit for a regular speaker
slot. The web application allows to do that, but the Devoxx newsletter
says it "allows you to submit Tools in Action, BOFs and Quickie
proposals"

Anyway, since I'm planning to go, I'd like to understand if you are
interested in organizing an o...@apache BOF. The goal would be to give
an overview of what's happening in and around Felix (including Karaf,
Ace and new tools like the Sigil Eclipse plugin if it's ready) and of
course discuss about osgi development.

WDYT?

I can take care about submitting the BOF and preparing a brief
presentation, but of course the more we are, the better it is.


Count me in, I think this is a great idea. It sure would not hurt to 
try and get a normal talk, but a BOF would be nice too.


Greetings, Marcel

Re: o...@apache: Devoxx BOF proposal?

2009-06-24 Thread Marcel Offermans



On Jun 23, 2009, at 11:52 , Filippo Diotalevi wrote:


Hi,
 as I was mentioning to some Felix' guys in Zurich, the call for
paper for Devoxx is open at:
http://presentations.devoxx.com/com.javoxx.cfp.CFPMain/CFPMain.html
(firefox only, I guess)

Devoxx will be held in Antwerp, NL, on Nov 16-20th.


Antwerp is in Belgium. :)


I'm not completely sure it is possible to submit for a regular speaker
slot. The web application allows to do that, but the Devoxx newsletter
says it "allows you to submit Tools in Action, BOFs and Quickie
proposals"

Anyway, since I'm planning to go, I'd like to understand if you are
interested in organizing an o...@apache BOF. The goal would be to give
an overview of what's happening in and around Felix (including Karaf,
Ace and new tools like the Sigil Eclipse plugin if it's ready) and of
course discuss about osgi development.

WDYT?

I can take care about submitting the BOF and preparing a brief
presentation, but of course the more we are, the better it is.


Count me in, I think this is a great idea. It sure would not hurt to  
try and get a normal talk, but a BOF would be nice too.


Greetings, Marcel

[jira] Updated: (FELIX-1266) [gogo] Provide a maven build for gogo

2009-06-24 Thread Filippo Diotalevi (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-1266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Filippo Diotalevi updated FELIX-1266:
-

Attachment: FELIX-1266.txt

The maven test failure is caused by a (java) assert failure at 
ThreadIOImpl.java:113

If I understand correctly the problem is when the second, third, ... Pipe of a 
closure is created ( see [1], method connect(Pipe) ), the next.setErr(...) 
method is not called, thus not initializing the "err" printstream

The submitted patch initialize the err printstream.

[1] 
http://svn.apache.org/repos/asf/felix/trunk/gogo/src/main/java/org/apache/felix/gogo/shell/runtime/Pipe.java

> [gogo] Provide a maven build for gogo
> -
>
> Key: FELIX-1266
> URL: https://issues.apache.org/jira/browse/FELIX-1266
> Project: Felix
>  Issue Type: Task
>  Components: Gogo
>Reporter: Guillaume Nodet
>Assignee: Guillaume Nodet
> Attachments: FELIX-1266.txt
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: New feature in FileInstall

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.diotal...@gmail.com> wrote:

> On Wed, Jun 24, 2009 at 5:39 PM, 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.
>
> 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

My intention was to update only when the link file is updated.

On Wed, Jun 24, 2009 at 8:30 PM, Filippo Diotalevi <
filippo.diotal...@gmail.com> wrote:

> On Wed, Jun 24, 2009 at 5:39 PM, 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.
>
> 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

2009-06-24 Thread Filippo Diotalevi

On Wed, Jun 24, 2009 at 5:39 PM, 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.

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

[jira] Updated: (FELIX-1276) There is no way to get all the Feature information from the FeaturesService


 [ 
https://issues.apache.org/jira/browse/FELIX-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim Moloney updated FELIX-1276:
---

Attachment: FELIX-1276-GetInstalledFeatures.patch

This patch adds the following method to FeaturesService.

Feature[] getInstalledFeatures()


> There is no way to get all the Feature information from the FeaturesService
> ---
>
> Key: FELIX-1276
> URL: https://issues.apache.org/jira/browse/FELIX-1276
> Project: Felix
>  Issue Type: Improvement
>  Components: Karaf
>Reporter: Tim Moloney
> Attachments: FELIX-1276-GetInstalledFeatures.patch
>
>
> There is no way to get Feature information from the FeaturesService, other 
> than "string-scraping", which only provides name, version, and state.
> Add a way to get the Feature objects so that all the Feature information can 
> be accessed (depedencies, bundles, configuration, etc.).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1276) There is no way to get all the Feature information from the FeaturesService

There is no way to get all the Feature information from the FeaturesService
---

 Key: FELIX-1276
 URL: https://issues.apache.org/jira/browse/FELIX-1276
 Project: Felix
  Issue Type: Improvement
  Components: Karaf
Reporter: Tim Moloney


There is no way to get Feature information from the FeaturesService, other than 
"string-scraping", which only provides name, version, and state.

Add a way to get the Feature objects so that all the Feature information can be 
accessed (depedencies, bundles, configuration, etc.).


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (FELIX-1275) On the Bundles page, when bundle details are displayed inline, the links to imported and importing bundles are invalid.


 [ 
https://issues.apache.org/jira/browse/FELIX-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim Moloney updated FELIX-1275:
---

Attachment: FELIX-1275-FixBundleUrlsInInlineDetails.patch

This patch uses the pluginRoot javascript variable to create the correct URL 
regardless of the current URL.

> On the Bundles page, when bundle details are displayed inline, the links to 
> imported and importing bundles are invalid.
> ---
>
> Key: FELIX-1275
> URL: https://issues.apache.org/jira/browse/FELIX-1275
> Project: Felix
>  Issue Type: Bug
>  Components: Web Console
>Reporter: Tim Moloney
>Priority: Minor
> Attachments: FELIX-1275-FixBundleUrlsInInlineDetails.patch
>
>
> This occurs in the trunk (1.2.11-SNAPSHOT).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (FELIX-1275) On the Bundles page, when bundle details are displayed inline, the links to imported and importing bundles are invalid.

On the Bundles page, when bundle details are displayed inline, the links to 
imported and importing bundles are invalid.
---

 Key: FELIX-1275
 URL: https://issues.apache.org/jira/browse/FELIX-1275
 Project: Felix
  Issue Type: Bug
  Components: Web Console
Reporter: Tim Moloney
Priority: Minor


This occurs in the trunk (1.2.11-SNAPSHOT).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (FELIX-1211) How to provide resources like CSS or JavaScript files for plugins


[ 
https://issues.apache.org/jira/browse/FELIX-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723633#action_12723633
 ] 

Tim Moloney commented on FELIX-1211:


The patch works well.

However, if the resource is not found, there is a NPE when attempting to 
execute ins.close() in the finally clause of spoolResource().


> How to provide resources like CSS or JavaScript files for plugins
> -
>
> Key: FELIX-1211
> URL: https://issues.apache.org/jira/browse/FELIX-1211
> Project: Felix
>  Issue Type: Sub-task
>  Components: Web Console
>Affects Versions: webconsole-1.2.10
>Reporter: Felix Meschberger
> Attachments: FELIX-1211-getResource.patch
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Release plan/date for maven-bundle-plugin?

2009-06-24 Thread Stuart McCulloch

2009/6/16 Kristian Köhler 

> Hi
>
> is there any plan or date for a new maven-bundle-plugin release? Version
> 2.0.0 was release about 3 month ago and there are some new features and
> bugfixes available.
>

the plan is basically kept in JIRA... there are still a number of issues
targeting the next release

I don't have any firm date of the next release as it depends on so many
variables (like how much spare time I have)

are there any particular fixes you are urgently waiting for?


> Not sure if it's neccessary to update but there is also a newer bnd version
> available (http://www.aqute.biz/repo/biz/aQute/bnd/0.0.313/). ;-)
>

actually the latest is 0.0.336 but we need the artifact available on Maven
central to avoid adding Peters repository to all bundle projects (up to now
we've had to request manual uploads for each version of the Bnd Tool we want
on central, because we don't own the "biz/aQute" groupId)

Thanks
> Kristian
>

-- 
Cheers, Stuart

Re: New feature in FileInstall

2009-06-24 Thread Stuart McCulloch

2009/6/24 Dennis Geurts 

> 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"  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
> > wrote:
> >
> >> On 6/24/09 8:52 AM, Filippo Diotalevi wrote:
> >>
> >>> On Wed, Jun 24, 2009 at 2:32 PM, Alin
> >>> Dreghiciu
> >>> 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: [VOTE] Apache Felix HTTP Service Jetty 1.0.1


+1

-> richard

p.s. This is my first attempt at releasing (uh oh), so you will need to 
download my key from the KEYS file.



On 6/24/09 12:05 PM, Richard S. Hall wrote:

This release of Apache Felix HTTP Service Jetty addresses this issue:

http://issues.apache.org/jira/browse/FELIX-1236

Staging repository:
https://repository.apache.org/content/repositories/felix-staging-008/

You can use this UNIX script to download the release and verify the 
signatures:

http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 008 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.

Version management in JIRA


Hey guys,


I notice that we aren't very good about creating/managing release 
versions in JIRA -- we need to make sure we create versions and close 
versions are part of the release process. Also, if you create a version 
make sure you properly select the preceding version so it appears in 
correct sorted order.



I think there might be a bug in JIRA where it doesn't correctly save the 
preceding version, because I notice lots that are not correct and I just 
created a version and it did not save it correctly even though I set it. 
I went back and manually edited the version description and it appears 
to be correct. So, I guess we need to verify it is correct after 
creating a version.


Thanks.

-> richard

[VOTE] Apache Felix HTTP Service Jetty 1.0.1


This release of Apache Felix HTTP Service Jetty addresses this issue:

http://issues.apache.org/jira/browse/FELIX-1236

Staging repository:
https://repository.apache.org/content/repositories/felix-staging-008/

You can use this UNIX script to download the release and verify the 
signatures:

http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh

Usage:
sh check_staged_release.sh 008 /tmp/felix-staging

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.

Re: New feature in FileInstall

2009-06-24 Thread Dennis Geurts

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"  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  
> wrote:
>
>> On 6/24/09 8:52 AM, Filippo Diotalevi wrote:
>>
>>> On Wed, Jun 24, 2009 at 2:32 PM, Alin  
>>> Dreghiciu
>>> 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

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. Hallwrote:

On 6/24/09 8:52 AM, Filippo Diotalevi wrote:

On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciu
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

2009-06-24 Thread Toni Menzel

If someone needs votes for doing this effectively, here's my +1

On Wed, Jun 24, 2009 at 5:39 PM, 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  >wrote:
>
> > On 6/24/09 8:52 AM, Filippo Diotalevi wrote:
> >
> >> On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciu
> >>  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
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: New feature in FileInstall

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 wrote:

> On 6/24/09 8:52 AM, Filippo Diotalevi wrote:
>
>> On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciu
>>  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.

[jira] Closed: (FELIX-1254) Bundle#findEntries does not return resources from fragments

2009-06-24 Thread Sebastian Marsching (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sebastian Marsching closed FELIX-1254.
--


Thanks for commiting the patch so quickly. I again tested with the latest 
version from SVN and the problem seems to be fixed now.


> Bundle#findEntries does not return resources from fragments
> ---
>
> Key: FELIX-1254
> URL: https://issues.apache.org/jira/browse/FELIX-1254
> Project: Felix
>  Issue Type: Bug
>  Components: Framework
>Affects Versions: felix-1.8.0
> Environment: Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode)
>Reporter: Sebastian Marsching
>Assignee: Richard S. Hall
> Fix For: felix-2.0.0
>
> Attachments: felix_FindEntriesEnumeration.patch
>
>
> In FELIX-1249 the ModuleImpl.getEntries() method has been fixed in order to 
> search not only the bundle itself but consider attached fragments, too. 
> However, this fix is not complete and therefore Bundle.findEntries(...) is 
> still not working correctly:
> In FindEntriesEnumeration.findNext(...) (FindEntriesEnumeration.java, line 
> 116) m_bundle.getCurrentModule().getEntry(...) is used to get the URL for the 
> matching entry. However, if the entry comes from a fragment, this method 
> returns null, which is correct as getEntry(...) should only return entries 
> from the bundle itself, not from attached fragments.
> Therefore, FindEntriesEnumeration.findNext(...) has to take into account from 
> which fragment (or the bundle itself) a matching entry is coming and use the 
> getEntry(...) method of the corresponding fragment. In order to accomplish 
> this task, instead of using CompoundEnumeration the FindEntriesEnumeration 
> implementation should take care of searching the bundle and its attached 
> fragments step by step. Thus it knows the fragment a matching entry is coming 
> from and can get the entry from the correct fragment.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: New feature in FileInstall

On 6/24/09 8:52 AM, Filippo Diotalevi wrote:

On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciu 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".

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

2009-06-24 Thread Filippo Diotalevi

On Wed, Jun 24, 2009 at 2:32 PM, Alin Dreghiciu 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

[jira] Closed: (FELIX-1179) FileInstall should recognize Jar files by content instead of extension

2009-06-24 Thread Sahoo (JIRA)


 [ 
https://issues.apache.org/jira/browse/FELIX-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sahoo closed FELIX-1179.



> FileInstall should recognize Jar files by content instead of extension
> --
>
> Key: FELIX-1179
> URL: https://issues.apache.org/jira/browse/FELIX-1179
> Project: Felix
>  Issue Type: Improvement
>  Components: File Install
>Affects Versions:  fileinstall-1.0.0
> Environment: generic
>Reporter: Sahoo
>Assignee: Richard S. Hall
> Fix For: fileinstall-1.2.0
>
> Attachments: FELIX-1179-2.txt, FELIX-1179.txt
>
>
> Currently FileInstall recognizes files of two types: .cfg files and .jar 
> files. I know there is already a request to have a plugin mechanism in 
> FileInstall to support different kinds of file types, but that's more of a 
> long term change. In short term, we can modify fileinstall to recognize Jar 
> files by their content instead of going by just file extensions. It will 
> allow us to use files like .war files in watched dir.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

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: [VOTE] Felix 1.8.1 framework and main subproject releases

2009-06-24 Thread Toni Menzel

+1

On 6/24/09, Stuart McCulloch  wrote:
> 2009/6/21 Karl Pauls 
>
>> I would like to call a vote on the framework and main 1.8.1 subproject
>> releases.
>>
>> This is a bug fix release mainly to allow felix to run with limited
>> permissions when a security manager is installed.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/felix-staging-003/
>>
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 3 /tmp/felix-staging
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>>
>
> +1
>
> --
> Cheers, Stuart
>


-- 
Toni Menzel
Independent Software Developer
Professional Profile: http://okidokiteam.com
t...@okidokiteam.com
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.

Re: [VOTE] Felix 1.8.1 framework and main subproject releases

2009-06-24 Thread Karl Pauls

On Wed, Jun 24, 2009 at 2:04 PM, Alin Dreghiciu wrote:
> +1 (non binding)When to expect the release? I'm planning to release Pax
> Runner soon and I want to include also support for 1.8.1.

Tomorrow.

regards,

Karl

> On Sun, Jun 21, 2009 at 6:07 PM, Karl Pauls  wrote:
>
>> I would like to call a vote on the framework and main 1.8.1 subproject
>> releases.
>>
>> This is a bug fix release mainly to allow felix to run with limited
>> permissions when a security manager is installed.
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/felix-staging-003/
>>
>> You can use this UNIX script to download the release and verify the
>> signatures:
>> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>>
>> Usage:
>> sh check_staged_release.sh 3 /tmp/felix-staging
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>>
>
>
>
> --
> 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.
>



-- 
Karl Pauls
karlpa...@gmail.com

Re: [VOTE] Felix 1.8.1 framework and main subproject releases

2009-06-24 Thread Stuart McCulloch

2009/6/21 Karl Pauls 

> I would like to call a vote on the framework and main 1.8.1 subproject
> releases.
>
> This is a bug fix release mainly to allow felix to run with limited
> permissions when a security manager is installed.
>
> Staging repository:
> https://repository.apache.org/content/repositories/felix-staging-003/
>
> You can use this UNIX script to download the release and verify the
> signatures:
> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh
>
> Usage:
> sh check_staged_release.sh 3 /tmp/felix-staging
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>

+1

-- 
Cheers, Stuart

Re: [VOTE] Felix 1.8.1 framework and main subproject releases