Congratulations!
Really likes to attend because I'm using Felix embedded to develop a system,
but unfortunately I'm living far away, in Sri Lanka.
Sameera
On 5/23/07, Rob Walker <[EMAIL PROTECTED]> wrote:
Many congrats Richard.
Would love to be there to support, but travels will probably pre
Many congrats Richard.
Would love to be there to support, but travels will probably prevent. Will keep
the date in mind in case Nov is free somehow though!
Feel free to use or reference us and/or our usage though if it's relevant - and
let me know if there's any specific info that you need.
On 23/05/07, BJ Hargrave <[EMAIL PROTECTED]> wrote:
It is not part of the framework package, but it is a key class to use for
services. Perhaps OSGi should consider moving it from Compendium to Core
spec?
if so, would the proposed BundleTracker (osgi issue 501) be added to
Core/Compendium?
--
On Monday 21 May 2007 23:23, Richard S. Hall wrote:
> The Felix PMC has voted to ask Clement Escoffier to be a committer
He wasn't already?? In that case; PMC, about time! ;o)
Clement, Congratulation and welcome to the ASF.
Cheers
--
Niclas Hedhman, Software Developer
I live here; http://ti
On Wednesday 23 May 2007 03:24, BJ Hargrave wrote:
> Perhaps OSGi should consider moving it from Compendium to Core
> spec?
I agree on this point.
> > It just
> > increases the size of the core.
> 14KB won't break the bank.
I suspect that if it was an integral part of the Framework, the size c
[
https://issues.apache.org/jira/browse/FELIX-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Moloney updated FELIX-219:
--
Attachment: maven-bundle-plugin-obr-5.patch
Added maven-bundle-plugin-obr-5.patch which is patched again
On 23/05/07, Tim Moloney <[EMAIL PROTECTED]> wrote:
Richard S. Hall wrote:
> Stuart McCulloch wrote:
>> On 22/05/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
>>> In summary, the dilemma we had was that everyone wanted the artifactId
>>> to be the short name and the JAR file to be the long name.
Richard S. Hall wrote:
Stuart McCulloch wrote:
On 22/05/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
In summary, the dilemma we had was that everyone wanted the artifactId
to be the short name and the JAR file to be the long name. But if we
made the artifactId the short name, then we also got
The installer does not include the bundles and does not start correctly
---
Key: FELIX-293
URL: https://issues.apache.org/jira/browse/FELIX-293
Project: Felix
Issue Type: Bu
[
https://issues.apache.org/jira/browse/FELIX-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet updated FELIX-293:
--
Attachment: FELIX-293.patch
> The installer does not include the bundles and does not start corr
BJ Hargrave wrote:
> It is not part of the framework package, but it is a key class to use
for
> services. Perhaps OSGi should consider moving it from Compendium to
Core
> spec?
+1
Rick Litton
-Original Message-
From: BJ Hargrave [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 22, 2007
Marcel Offermans <[EMAIL PROTECTED]> wrote on 2007-05-22
13:20:51:
> On May 22, 2007, at 18:07 , Richard S. Hall wrote:
>
> > Since the overall response has been positive (even though I am
> > mostly in the "excess cruft" camp with Eric), I have gone ahead and
> > added it.
>
> I'm also in tha
Stuart McCulloch wrote:
On 22/05/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
In summary, the dilemma we had was that everyone wanted the artifactId
to be the short name and the JAR file to be the long name. But if we
made the artifactId the short name, then we also got the short name for
the
Hey everyone,
I just received word that my proposal for ApacheCon on embedding Felix
was accepted. That means I need to get everyone to show up so I am not
talking to an empty room! I guess that also means that I will need to
start working on the slides... :-o
Anyone else make an OSGi/Felix-
Marcel Offermans wrote:
On May 22, 2007, at 18:07 , Richard S. Hall wrote:
Since the overall response has been positive (even though I am mostly
in the "excess cruft" camp with Eric), I have gone ahead and added it.
I'm also in that camp, but I was at a conference (without internet)
today, s
Peter Kriens wrote:
One of the design goals of the ServiceTracker was that it could be
optimized by framework vendors. If you look at the implementation, you
will see that there are some inefficiencies in the implementation
because it must use the standard listeners (it must listen to all
service
One of the design goals of the ServiceTracker was that it could be
optimized by framework vendors. If you look at the implementation, you
will see that there are some inefficiencies in the implementation
because it must use the standard listeners (it must listen to all
service events when you use i
On May 22, 2007, at 18:07 , Richard S. Hall wrote:
Since the overall response has been positive (even though I am
mostly in the "excess cruft" camp with Eric), I have gone ahead and
added it.
I'm also in that camp, but I was at a conference (without internet)
today, so I missed out on the
Since the overall response has been positive (even though I am mostly in
the "excess cruft" camp with Eric), I have gone ahead and added it.
Besides other peoples' positive reaction, my feeling is that if people
aren't using iPOJO, DS, etc, then it is better to encourage people to
use ST than
On 22/05/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
In summary, the dilemma we had was that everyone wanted the artifactId
to be the short name and the JAR file to be the long name. But if we
made the artifactId the short name, then we also got the short name for
the JAR.
FYI, it is possibl
[
https://issues.apache.org/jira/browse/FELIX-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497896
]
Richard S. Hall commented on FELIX-285:
---
I will close this issue then, but feel free to keep commenting on it fo
[
https://issues.apache.org/jira/browse/FELIX-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard S. Hall closed FELIX-285.
-
> Make resolver more robust
> -
>
> Key: FELIX-285
>
On 22/05/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
Sure, I'll raise a JIRA and attach the patch.
But if anyone has any idea of how the substitution occurs ...
from what I can tell, INSTALL_PATH is substituted by the izpack tool:
http://svn.berlios.de/svnroot/repos/izpack/izpack-src/br
Stuart McCulloch wrote:
if it is included in the framework jar, how easy would it be
to replace it with another implementation at deploy time?
( don't know if this is a likely scenario ... just wondering )
You should still be able to load a different version of it in a separate
bundle.
-> r
can you please remove me from the mailing list
-
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
Hello everyone
A big thank-you to all, and specially to Rick which apply all my patches
during the past year.
Clement
Richard S. Hall a écrit :
The Felix PMC has voted to ask Clement Escoffier to be a committer and
he has accepted. We are just waiting for his user account to be
created, the
[
https://issues.apache.org/jira/browse/FELIX-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497876
]
Bart Elen commented on FELIX-285:
-
I just had a look at the newly submitted code. It's looking good and my tests
are
+1
RSH> Should Felix start including ServiceTracker in the framework JAR file?
RSH> Up until now, it has never been included because the framework doesn't
RSH> use it, so it is just extra cruft and can easily be downloaded
RSH> separately. However, it appears that other frameworks make it availa
if it is included in the framework jar, how easy would it be
to replace it with another implementation at deploy time?
( don't know if this is a likely scenario ... just wondering )
On 22/05/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Thomas Watson wrote:
> Here are a couple of reasons a Fra
On 22/05/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Clement Escoffier wrote:
> Hello,
>>
>> FELIX-219 Update maven-bundle-plugin to install bundles to a local
>> OBR
> We (in fact, Maxime Vincent) have developed an independent Maven
> plugin installing bundles in a local OBR. This plugin i
No. LIke you said, it's just extra cruft.
> Should Felix start including ServiceTracker in the framework JAR file?
>
> Up until now, it has never been included because the framework doesn't
> use it, so it is just extra cruft and can easily be downloaded
> separately. However, it appears that oth
Hi,
I also think, that including it would be a good thing. This would probably
also propagate its use further ...
Regards
Felix
On 5/22/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Should Felix start including ServiceTracker in the framework JAR file?
Up until now, it has never been includ
Hi Richard,
On 5/22/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Sounds like a reasonable argument to me, but then how do we resolve this
issue for the installer? Is there any way to get the installer to
automatically substitute ${felix.home} with a properly encoded string?
Unfortunately n
Thomas Watson wrote:
Here are a couple of reasons a Framework may want to include the
ServiceTracker:
1) The Framework uses the ServiceTracker to implement things like
the URL Handlers Service Specification. The Framework could have only
used ServiceTracker internally and not exported it for
Here are a couple of reasons a Framework may want to include the
ServiceTracker:
1) The Framework uses the ServiceTracker to implement things like
the URL Handlers Service Specification. The Framework could have only
used ServiceTracker internally and not exported it for others to use.
2) Perf
BJ Hargrave wrote:
I would say yes. You can then look at performance optimizations which take
advantage of framework internals.
You could even package it as a framework extension fragment :-)
Packaging it as a extension bundle would defeat the purpose...the issue
is that more and more peo
Sure, I'll raise a JIRA and attach the patch.
But if anyone has any idea of how the substitution occurs ...
On 5/22/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
Guillaume Nodet wrote:
> I guess I have been a bit misleaded by the fact that the
> config.propertiesfile
> is not included by defau
I would say yes. You can then look at performance optimizations which take
advantage of framework internals.
You could even package it as a framework extension fragment :-)
--
BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
[EMAIL PROTECTED]
office: +1 3
Guillaume Nodet wrote:
I guess I have been a bit misleaded by the fact that the
config.propertiesfile
is not included by default in the installers. After including the one
provided, it seems
to work because the following syntax is used:
felix.auto.start.1= \
file:%INSTALL_PATH/bundle/org.apach
As in a conversation I had with Peter Kriens he was pointing out that he
could not think of a useful use case where the raw service listener can be
used due to the missing of the events raised before.
And what's the then the listener? The ServiceTracker.
In my view it's qualifying for being part
I guess I have been a bit misleaded by the fact that the config.propertiesfile
is not included by default in the installers. After including the one
provided, it seems
to work because the following syntax is used:
felix.auto.start.1= \
file:%INSTALL_PATH/bundle/org.apache.felix.shell-1.0-SNAPSHO
Richard S. Hall wrote:
> Should Felix start including ServiceTracker in the framework JAR file?
>
You know my opinion but just for the record, I would go for it.
+1 from my side :)
> Up until now, it has never been included because the framework doesn't
> use it, so it is just extra cruft and ca
Should Felix start including ServiceTracker in the framework JAR file?
Up until now, it has never been included because the framework doesn't
use it, so it is just extra cruft and can easily be downloaded
separately. However, it appears that other frameworks make it available
by default.
Tho
Felix Meschberger wrote:
But the property AFAIK is a list of URLs not file system paths. You
may also
specify HTTP or whatever URLs you expect to be supported.
Adding support for relative paths resolved locally, you temporarily help
until you come up with a relative path containing blanks again
Clement Escoffier wrote:
Hello,
FELIX-219 Update maven-bundle-plugin to install bundles to a local
OBR
We (in fact, Maxime Vincent) have developed an independent Maven
plugin installing bundles in a local OBR. This plugin is very close to
the Felix-219 patch. However, there is a differenc
Hi,
But the property AFAIK is a list of URLs not file system paths. You may also
specify HTTP or whatever URLs you expect to be supported.
Adding support for relative paths resolved locally, you temporarily help
until you come up with a relative path containing blanks again and your are
back to
Yeah, but I would assume that Felix is independent of the installation
folder
and thus you don't have to specify the absolute path when loading bundles.
The problem is in the "C:\Program Files\felix-xxx", that's why I suggested
to
resolve bundles uris from the home dir.
On 5/22/07, Felix Meschber
On 22/05/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
Hi,
I also had this problem and it turns out, that the URLs are actually wrong
because space is an unsafe character ([1]) and must always be encoded.
Unfortunately, the java.io.File.toURL() method handles blanks in path names
incorrectly
Hi,
I also had this problem and it turns out, that the URLs are actually wrong
because space is an unsafe character ([1]) and must always be encoded.
Unfortunately, the java.io.File.toURL() method handles blanks in path names
incorrectly and does NOT encoded them. The workaround since Java 1.4 is
49 matches
Mail list logo
