Re: [DISCUSS] Move Karaf as a TLP
I'd like to be a part of this TLP. many thanks david jencks On May 27, 2010, at 10:40 PM, Guillaume Nodet wrote: It seems there is a consensus to move Karaf as a TLP, at least amongst people involved in Karaf (the other felix committers haven't really expressed any opinion). I think the next steps would be to draft a proposed resolution to the board, which would include: * the project goal * the project PMC (including the chair) In order to create an open community from the start, I'd like to invite anyone with an Apache account willing to contribute to Karaf to raise hands so that we can build this list. I don't think opening it wider for now would be wise, but I do thing we should have a very low entry bar for committership (but that can be discussed later). I'll try to come up with a proposal for Karaf's project goal asap, but anyone is welcome to give it a try and propose some wording. FWIW, it would like the following, we just need to fill the : WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a machine learning platform for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Karaf Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Karaf Project be and hereby is responsible for the creation and maintenance of software related to XXX; and be it further RESOLVED, that the office of Vice President, Apache Karaf be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Karaf Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Karaf Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Karaf Project: * xxx x...@apache.org * ... NOW, THEREFORE, BE IT FURTHER RESOLVED, that X be appointed to the office of Vice President, Apache Karaf, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Karaf PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Mahout Project; and be it further RESOLVED, that the Apache Karaf Project be and hereby is tasked with the migration and rationalization of the Apache Felix Karaf sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Felix Karaf sub-project encumbered upon the Apache Felix Project are hereafter discharged. On Fri, May 14, 2010 at 12:20, Guillaume Nodet gno...@gmail.com wrote: Karaf has been brought into the Felix TLP nearly one year ago. Things have not been too bad, but I still see the karaf community as being very disjoint from the other felix community, as it looks that none of the existing felix committers did really get involved in Karaf. I really don't blame anyone, i think it's just that the interest are not the same (not sure where they actually diverge though). I don't really see what benefit Karaf would have in continuing being part of Felix, so I'd like to open the discussion about moving it to a TLP. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [DISCUSS] Move Karaf as a TLP
Likewise I'd also like to participate and agree that this is the right direction for Karaf. Count me in. Regards, Alex Karasulu On Fri, May 28, 2010 at 9:37 AM, David Jencks david_jen...@yahoo.comwrote: I'd like to be a part of this TLP. many thanks david jencks On May 27, 2010, at 10:40 PM, Guillaume Nodet wrote: It seems there is a consensus to move Karaf as a TLP, at least amongst people involved in Karaf (the other felix committers haven't really expressed any opinion). I think the next steps would be to draft a proposed resolution to the board, which would include: * the project goal * the project PMC (including the chair) In order to create an open community from the start, I'd like to invite anyone with an Apache account willing to contribute to Karaf to raise hands so that we can build this list. I don't think opening it wider for now would be wise, but I do thing we should have a very low entry bar for committership (but that can be discussed later). I'll try to come up with a proposal for Karaf's project goal asap, but anyone is welcome to give it a try and propose some wording. FWIW, it would like the following, we just need to fill the : WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a machine learning platform for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Karaf Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Karaf Project be and hereby is responsible for the creation and maintenance of software related to XXX; and be it further RESOLVED, that the office of Vice President, Apache Karaf be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Karaf Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Karaf Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Karaf Project: * xxx x...@apache.org * ... NOW, THEREFORE, BE IT FURTHER RESOLVED, that X be appointed to the office of Vice President, Apache Karaf, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Karaf PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Mahout Project; and be it further RESOLVED, that the Apache Karaf Project be and hereby is tasked with the migration and rationalization of the Apache Felix Karaf sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Felix Karaf sub-project encumbered upon the Apache Felix Project are hereafter discharged. On Fri, May 14, 2010 at 12:20, Guillaume Nodet gno...@gmail.com wrote: Karaf has been brought into the Felix TLP nearly one year ago. Things have not been too bad, but I still see the karaf community as being very disjoint from the other felix community, as it looks that none of the existing felix committers did really get involved in Karaf. I really don't blame anyone, i think it's just that the interest are not the same (not sure where they actually diverge though). I don't really see what benefit Karaf would have in continuing being part of Felix, so I'd like to open the discussion about moving it to a TLP. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: File install 3.0.0 - avoiding property substitution
Hello Guillaume,
Thanks for your reply. However, if I escape the string the way you describe,
then the backslash will remain in the string. The result will be:
file://inbox?move=backup/$\{date:now:yyyMMdd\}/$\{file:name\}
What I want is:
file://inbox?move=backup/${date:now:yyyMMdd}/${file:name}
Otherwise the string will not be usable for Camel. Is there a way to
accomplish this? In general terms one usually has a way to quote
substrings in order to avoid substitution but the quotes themselves should
be removed from the string. In this case backslash is the quoting character
but it's not removed from the end result.
I think also that it would be good if one could escape substrings and not
only indiviudal characters (by enclosing substrings with quotes) but that
has lower priority for me if I can get the above to work.
I've been looking at the source code in file install (3.0) and understand
why this is happening. The method of interest is substVars in class
org.apache.felix.fileinstall.internal.Util. The logic tries to find
matching DELIM_START (${) and DELIM_STOP (}). When I escape either of these
(by specifying a backslash before ${ and/or }), the logic will never
find matching DELIM_START and DELIM_STOP which causes the method to
immediately return without performing property substitution. The logic at
the end of the method (that removes the backslashes) is never reached.
/Bengt
2010/5/27 Guillaume Nodet gno...@gmail.com
Sure, we had the same problem in Karaf and i've fixed that as part of
https://issues.apache.org/jira/browse/FELIX-2307
Basically, just add '\' before the '{' and '}' and it should work:
file://inbox?move=backup/$\{date:now:yyyMMdd\}/$\{file:name\}
On Thu, May 27, 2010 at 23:22, Bengt Rodehav be...@rodehav.com wrote:
Hello everyone,
My question didn't get much attention on my first attempt so I'll make
another one...
Maybe a clarifaction of what I'm trying to do helps. I'm using Karaf as a
deployment container for Camel routes. I start services, using file
install,
that house camel routes. The routes are configurable using the
configuration
admin via file install. E g I have a general file transfer route in Camel
that looks like this:
from(mFromUri).to(mToUri);
...where mFromUri and mToUri are properties configured via
configuration
admin. Camel itself supports a property concept and an example of a
mFromUri I might want to use is:
file://inbox?move=backup/${date:now:yyyMMdd}/${file:name}
This will cause Camel to poll the inbox folder and archive completed
files
in a backup folder that is named with todays date.
However, since file install always does property substitution itself (in
this case I want Camel to do it - not file install), the URI sent to
Camel
will be:
file://inbox?move=backup//
This is because the strings ${date:now:yyyMMdd} and ${file:name} will be
transformed to empty strings since file install will regard them as
properties that are not defined.
How can I work around this? Any clues?
/Bengt
2010/5/26 Bengt Rodehav be...@rodehav.com
I'm using the File Install component and cannot find a way to set
values
like ${abc} (without the quotes). File install insists on performing
property substitution which I do not want in this case. I noticed that
this
seems to have been addressed in version 3.0.0 but I cannot get it to
work.
My question is: How can I set a value to ${abc} (without the quotes)
without File install trying to perform property substitution?
/Bengt
--
Cheers,
Guillaume Nodet
Blog: http://gnodet.blogspot.com/
Open Source SOA
http://fusesource.com
[jira] Updated: (FELIX-2344) DM / callback method is not invoked when an extra dependency is defined within an init component method.
[ https://issues.apache.org/jira/browse/FELIX-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre De Rop updated FELIX-2344: - Attachment: FELIX2344_ExtraDependencyWithCallbackTest.java Marcel, The last commit seems to resolve every callback issues. But, now, in my environment, I went further on and I think I came across another issue: this time it concerns optional/autoconfig dependencies: So, if you define an optional/autoconfig extra dependency from the init() method, then the autoconfig field seems to not be injected with a NullObject. I have attached to this issue a modified version of the testcase (see the sc5 consumer). DM / callback method is not invoked when an extra dependency is defined within an init component method. -- Key: FELIX-2344 URL: https://issues.apache.org/jira/browse/FELIX-2344 Project: Felix Issue Type: Bug Components: Dependency Manager Reporter: Pierre De Rop Attachments: FELIX2344_ExtraDependencyWithCallbackTest.java, sample.instancebound.tgz This issue applies to the trunk version of dependency manager. So, it seems that when a component defines custom dependencies from its init method, then such extra dependencies only support auto configuration mode, and not callbacks. I have attached to this issue a sample maven project which reproduces the problem: In the sample, a MyClient component is defining (from its init() method) an extra required dependency over a MyService service, using a bind callback. So, the start() method is invoked, but the bind method has not been called. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2366) Avoiding property substitution by escaping does not remove escape character
Avoiding property substitution by escaping does not remove escape character
---
Key: FELIX-2366
URL: https://issues.apache.org/jira/browse/FELIX-2366
Project: Felix
Issue Type: Bug
Components: File Install
Affects Versions: fileinstall-3.0.0
Reporter: Bengt Rodehav
To avoid property substitution, an escape character was introduced in version
3.0.0 of File Install. The idea is that if I want to send the configuration
value
${propkey}
to my application without property substitution to take place, I can escape the
START_DELIM (${) and STOP_DELIM (}) with a backslash as follows:
$\{propkey\}
However, when doing this the escape character is not removed from the string.
The reason is as follows:
The method of interest is substVars in class
org.apache.felix.fileinstall.internal.Util. The logic tries to find matching
DELIM_START (${) and DELIM_STOP (}). When you escape either of these (by
specifying a backslash before ${ and/or }), the logic will never find
matching DELIM_START and DELIM_STOP which causes the method to immediately
return without performing property substitution. The logic at the end of the
method (that removes the backslashes) is never reached.
A workarount is to add an unnecessary property at the end of the value just to
make sure some property substitution will take place since then the logic at
the end of the substVars() method (that removes the escape character) will be
reached. Thus, this works:
$\{propkey\}${#}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: File install 3.0.0 - avoiding property substitution
JIRA is raised: https://issues.apache.org/jira/browse/FELIX-2366
I tried your workaround and it works. Thanks.
BTW, when looking at the source code I find something a bit fishy. The loop
that tries to find the DELIM_START looks like this:
// Find the matching starting ${ variable delimiter
// by looping until we find a start delimiter that is
// greater than the stop delimiter we have found.
int startDelim = val.indexOf(DELIM_START);
while (stopDelim = 0)
{
int idx = val.indexOf(DELIM_START, startDelim +
DELIM_START.length());
if ((idx 0) || (idx stopDelim))
{
break;
}
else if (idx stopDelim)
{
startDelim = idx;
}
}
Should the loop condition really be while(stopDelim =0). I haven't seen
any erroneous behaviour but I cannot see that the stopDelim variable is ever
changed within the loop which means that the loop will run once or not at
all. Shouldn't the loop condition use startDelim?
/Bengt
2010/5/28 Guillaume Nodet gno...@gmail.com
This looks like a bug. Could you please raise a JIRA for that ?
As a workaround, you can try:
file://inbox?move=backup/$\{date:now:yyyMMdd\}/$\{file:name\}${#}
It will force a substitution, and thus will remove the escape chars.
On Fri, May 28, 2010 at 10:11, Bengt Rodehav be...@rodehav.com wrote:
Hello Guillaume,
Thanks for your reply. However, if I escape the string the way you
describe,
then the backslash will remain in the string. The result will be:
file://inbox?move=backup/$\{date:now:yyyMMdd\}/$\{file:name\}
What I want is:
file://inbox?move=backup/${date:now:yyyMMdd}/${file:name}
Otherwise the string will not be usable for Camel. Is there a way to
accomplish this? In general terms one usually has a way to quote
substrings in order to avoid substitution but the quotes themselves
should
be removed from the string. In this case backslash is the quoting
character
but it's not removed from the end result.
I think also that it would be good if one could escape substrings and not
only indiviudal characters (by enclosing substrings with quotes) but that
has lower priority for me if I can get the above to work.
I've been looking at the source code in file install (3.0) and understand
why this is happening. The method of interest is substVars in class
org.apache.felix.fileinstall.internal.Util. The logic tries to find
matching DELIM_START (${) and DELIM_STOP (}). When I escape either of
these
(by specifying a backslash before ${ and/or }), the logic will never
find matching DELIM_START and DELIM_STOP which causes the method to
immediately return without performing property substitution. The logic at
the end of the method (that removes the backslashes) is never reached.
/Bengt
2010/5/27 Guillaume Nodet gno...@gmail.com
Sure, we had the same problem in Karaf and i've fixed that as part of
https://issues.apache.org/jira/browse/FELIX-2307
Basically, just add '\' before the '{' and '}' and it should work:
file://inbox?move=backup/$\{date:now:yyyMMdd\}/$\{file:name\}
On Thu, May 27, 2010 at 23:22, Bengt Rodehav be...@rodehav.com
wrote:
Hello everyone,
My question didn't get much attention on my first attempt so I'll
make
another one...
Maybe a clarifaction of what I'm trying to do helps. I'm using Karaf
as
a
deployment container for Camel routes. I start services, using file
install,
that house camel routes. The routes are configurable using the
configuration
admin via file install. E g I have a general file transfer route in
Camel
that looks like this:
from(mFromUri).to(mToUri);
...where mFromUri and mToUri are properties configured via
configuration
admin. Camel itself supports a property concept and an example of a
mFromUri I might want to use is:
file://inbox?move=backup/${date:now:yyyMMdd}/${file:name}
This will cause Camel to poll the inbox folder and archive completed
files
in a backup folder that is named with todays date.
However, since file install always does property substitution itself
(in
this case I want Camel to do it - not file install), the URI sent to
Camel
will be:
file://inbox?move=backup//
This is because the strings ${date:now:yyyMMdd} and ${file:name} will
be
transformed to empty strings since file install will regard them as
properties that are not defined.
How can I work around this? Any clues?
/Bengt
2010/5/26 Bengt Rodehav be...@rodehav.com
I'm using the File Install component and cannot find a way to set
values
like ${abc} (without the quotes). File install insists on
performing
property substitution which I do not want in this case. I noticed
that
this
seems
[jira] Resolved: (FELIX-2366) Avoiding property substitution by escaping does not remove escape character
[
https://issues.apache.org/jira/browse/FELIX-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guillaume Nodet resolved FELIX-2366.
Assignee: Guillaume Nodet
Fix Version/s: fileinstall-3.1.0
Resolution: Fixed
Committing to https://svn.apache.org/repos/asf/felix/trunk ...
M
fileinstall/src/main/java/org/apache/felix/fileinstall/internal/Util.java
M
fileinstall/src/test/java/org/apache/felix/fileinstall/internal/UtilTest.java
Committed r949136
Avoiding property substitution by escaping does not remove escape character
---
Key: FELIX-2366
URL: https://issues.apache.org/jira/browse/FELIX-2366
Project: Felix
Issue Type: Bug
Components: File Install
Affects Versions: fileinstall-3.0.0
Reporter: Bengt Rodehav
Assignee: Guillaume Nodet
Fix For: fileinstall-3.1.0
To avoid property substitution, an escape character was introduced in version
3.0.0 of File Install. The idea is that if I want to send the configuration
value
${propkey}
to my application without property substitution to take place, I can escape
the START_DELIM (${) and STOP_DELIM (}) with a backslash as follows:
$\{propkey\}
However, when doing this the escape character is not removed from the string.
The reason is as follows:
The method of interest is substVars in class
org.apache.felix.fileinstall.internal.Util. The logic tries to find matching
DELIM_START (${) and DELIM_STOP (}). When you escape either of these (by
specifying a backslash before ${ and/or }), the logic will never find
matching DELIM_START and DELIM_STOP which causes the method to immediately
return without performing property substitution. The logic at the end of the
method (that removes the backslashes) is never reached.
A workarount is to add an unnecessary property at the end of the value just
to make sure some property substitution will take place since then the logic
at the end of the substVars() method (that removes the escape character) will
be reached. Thus, this works:
$\{propkey\}${#}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Error with UPnP Base driver
On 27/05/2010 14.47, charbel el_kaed wrote: Hi Stefano, This is the wiring I had: === start 4 ... DEBUG: WIRE: 4.0 - javax.xml.parsers - 0 DEBUG: WIRE: 4.0 - org.w3c.dom - 20.0 DEBUG: WIRE: 4.0 - org.xml.sax - 22.0 I believe that the problem is caused by the wiring above. In fact, considering that you are using Java 6 you should have all the above wiring should pointing at bundle 0. Felix fails to resolve the wiring to bundle 0 because the Import-Package and Export-Package headers of bundle 20 and 22 may be not correct. I think that the correct configuration of bundle 20 and 22 are: - bundle 20 and 22 import and export the packages: org.w3c.dom and org.xml.sax - bundle 20 and 22 ONLY import the packages: org.w3c.dom and org.xml.sax I hope it can help...
Re: File install 3.0.0 - avoiding property substitution
Yeah, that makes more sense.
2010/5/28 Guillaume Nodet gno...@gmail.com
I think the loop is correct, even though very weird.
I guess it should read as:
if (stopDelim = 0)
{
while (true)
{
...
}
}
On Fri, May 28, 2010 at 11:01, Bengt Rodehav be...@rodehav.com wrote:
JIRA is raised: https://issues.apache.org/jira/browse/FELIX-2366
I tried your workaround and it works. Thanks.
BTW, when looking at the source code I find something a bit fishy. The
loop
that tries to find the DELIM_START looks like this:
// Find the matching starting ${ variable delimiter
// by looping until we find a start delimiter that is
// greater than the stop delimiter we have found.
int startDelim = val.indexOf(DELIM_START);
while (stopDelim = 0)
{
int idx = val.indexOf(DELIM_START, startDelim +
DELIM_START.length());
if ((idx 0) || (idx stopDelim))
{
break;
}
else if (idx stopDelim)
{
startDelim = idx;
}
}
Should the loop condition really be while(stopDelim =0). I haven't
seen
any erroneous behaviour but I cannot see that the stopDelim variable is
ever
changed within the loop which means that the loop will run once or not at
all. Shouldn't the loop condition use startDelim?
/Bengt
2010/5/28 Guillaume Nodet gno...@gmail.com
This looks like a bug. Could you please raise a JIRA for that ?
As a workaround, you can try:
file://inbox?move=backup/$\{date:now:yyyMMdd\}/$\{file:name\}${#}
It will force a substitution, and thus will remove the escape chars.
On Fri, May 28, 2010 at 10:11, Bengt Rodehav be...@rodehav.com
wrote:
Hello Guillaume,
Thanks for your reply. However, if I escape the string the way you
describe,
then the backslash will remain in the string. The result will be:
file://inbox?move=backup/$\{date:now:yyyMMdd\}/$\{file:name\}
What I want is:
file://inbox?move=backup/${date:now:yyyMMdd}/${file:name}
Otherwise the string will not be usable for Camel. Is there a way to
accomplish this? In general terms one usually has a way to quote
substrings in order to avoid substitution but the quotes themselves
should
be removed from the string. In this case backslash is the quoting
character
but it's not removed from the end result.
I think also that it would be good if one could escape substrings and
not
only indiviudal characters (by enclosing substrings with quotes) but
that
has lower priority for me if I can get the above to work.
I've been looking at the source code in file install (3.0) and
understand
why this is happening. The method of interest is substVars in class
org.apache.felix.fileinstall.internal.Util. The logic tries to find
matching DELIM_START (${) and DELIM_STOP (}). When I escape either of
these
(by specifying a backslash before ${ and/or }), the logic will
never
find matching DELIM_START and DELIM_STOP which causes the method to
immediately return without performing property substitution. The
logic
at
the end of the method (that removes the backslashes) is never
reached.
/Bengt
2010/5/27 Guillaume Nodet gno...@gmail.com
Sure, we had the same problem in Karaf and i've fixed that as part
of
https://issues.apache.org/jira/browse/FELIX-2307
Basically, just add '\' before the '{' and '}' and it should work:
file://inbox?move=backup/$\{date:now:yyyMMdd\}/$\{file:name\}
On Thu, May 27, 2010 at 23:22, Bengt Rodehav be...@rodehav.com
wrote:
Hello everyone,
My question didn't get much attention on my first attempt so I'll
make
another one...
Maybe a clarifaction of what I'm trying to do helps. I'm using
Karaf
as
a
deployment container for Camel routes. I start services, using
file
install,
that house camel routes. The routes are configurable using the
configuration
admin via file install. E g I have a general file transfer route
in
Camel
that looks like this:
from(mFromUri).to(mToUri);
...where mFromUri and mToUri are properties configured via
configuration
admin. Camel itself supports a property concept and an example
of
a
mFromUri I might want to use is:
file://inbox?move=backup/${date:now:yyyMMdd}/${file:name}
This will cause Camel to poll the inbox folder and archive
completed
files
in a backup folder that is named with todays date.
However, since file install always does property substitution
itself
(in
this case I want Camel to do it - not file install), the URI sent
to
Camel
will be:
file://inbox?move=backup//
Re: [DISCUSS] Move Karaf as a TLP
+1 I'm on board :) Cheers, Jamie On Fri, May 28, 2010 at 4:34 AM, Alex Karasulu akaras...@apache.org wrote: Likewise I'd also like to participate and agree that this is the right direction for Karaf. Count me in. Regards, Alex Karasulu On Fri, May 28, 2010 at 9:37 AM, David Jencks david_jen...@yahoo.comwrote: I'd like to be a part of this TLP. many thanks david jencks On May 27, 2010, at 10:40 PM, Guillaume Nodet wrote: It seems there is a consensus to move Karaf as a TLP, at least amongst people involved in Karaf (the other felix committers haven't really expressed any opinion). I think the next steps would be to draft a proposed resolution to the board, which would include: * the project goal * the project PMC (including the chair) In order to create an open community from the start, I'd like to invite anyone with an Apache account willing to contribute to Karaf to raise hands so that we can build this list. I don't think opening it wider for now would be wise, but I do thing we should have a very low entry bar for committership (but that can be discussed later). I'll try to come up with a proposal for Karaf's project goal asap, but anyone is welcome to give it a try and propose some wording. FWIW, it would like the following, we just need to fill the : WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a machine learning platform for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Karaf Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Karaf Project be and hereby is responsible for the creation and maintenance of software related to XXX; and be it further RESOLVED, that the office of Vice President, Apache Karaf be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Karaf Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Karaf Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Karaf Project: * xxx x...@apache.org * ... NOW, THEREFORE, BE IT FURTHER RESOLVED, that X be appointed to the office of Vice President, Apache Karaf, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Karaf PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Mahout Project; and be it further RESOLVED, that the Apache Karaf Project be and hereby is tasked with the migration and rationalization of the Apache Felix Karaf sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Felix Karaf sub-project encumbered upon the Apache Felix Project are hereafter discharged. On Fri, May 14, 2010 at 12:20, Guillaume Nodet gno...@gmail.com wrote: Karaf has been brought into the Felix TLP nearly one year ago. Things have not been too bad, but I still see the karaf community as being very disjoint from the other felix community, as it looks that none of the existing felix committers did really get involved in Karaf. I really don't blame anyone, i think it's just that the interest are not the same (not sure where they actually diverge though). I don't really see what benefit Karaf would have in continuing being part of Felix, so I'd like to open the discussion about moving it to a TLP. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu
Re: Framework release coming soon
On 5/28/10 1:46, Rob Walker wrote: Nice one, will look forward to giving it a try in our environment. We're working on a reasonably up to date trunk, so I wouldn't foresee any major issues The sooner the better, since we are planning on releasing this weekend...if not, there are always maintenance releases! :-) - richard - R On 27/05/2010 8:49 PM, Richard S. Hall wrote: So, we are gearing up to release the 3.0 version of the framework. As part of this release, we're going to include Gogo as the default shell in the framework binary distribution. Gogo requires Java 5 or later, but don't worry, the framework still targets lesser JREs. :-) I've uploaded a snapshot of the distribution in tar.gz and zip if anyone wants to play with it: https://repository.apache.org/content/groups/snapshots-group/org/apache/felix/org.apache.felix.main.distribution/2.1.0-SNAPSHOT/ Word of warning, the ps command has been renamed to lb (i.e., list bundles)...type help to see available commands. - richard
Re: [DISCUSS] Move Karaf as a TLP
Question: Is a formal vote necessary to start this process or is our informal consensus enough? - richard On 5/28/10 1:40, Guillaume Nodet wrote: It seems there is a consensus to move Karaf as a TLP, at least amongst people involved in Karaf (the other felix committers haven't really expressed any opinion). I think the next steps would be to draft a proposed resolution to the board, which would include: * the project goal * the project PMC (including the chair) In order to create an open community from the start, I'd like to invite anyone with an Apache account willing to contribute to Karaf to raise hands so that we can build this list. I don't think opening it wider for now would be wise, but I do thing we should have a very low entry bar for committership (but that can be discussed later). I'll try to come up with a proposal for Karaf's project goal asap, but anyone is welcome to give it a try and propose some wording. FWIW, it would like the following, we just need to fill the : WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a machine learning platform for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Karaf Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Karaf Project be and hereby is responsible for the creation and maintenance of software related to XXX; and be it further RESOLVED, that the office of Vice President, Apache Karaf be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Karaf Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Karaf Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Karaf Project: * ...@apache.org * ... NOW, THEREFORE, BE IT FURTHER RESOLVED, that X be appointed to the office of Vice President, Apache Karaf, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Karaf PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Mahout Project; and be it further RESOLVED, that the Apache Karaf Project be and hereby is tasked with the migration and rationalization of the Apache Felix Karaf sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Felix Karaf sub-project encumbered upon the Apache Felix Project are hereafter discharged. On Fri, May 14, 2010 at 12:20, Guillaume Nodetgno...@gmail.com wrote: Karaf has been brought into the Felix TLP nearly one year ago. Things have not been too bad, but I still see the karaf community as being very disjoint from the other felix community, as it looks that none of the existing felix committers did really get involved in Karaf. I really don't blame anyone, i think it's just that the interest are not the same (not sure where they actually diverge though). I don't really see what benefit Karaf would have in continuing being part of Felix, so I'd like to open the discussion about moving it to a TLP. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Created: (FELIX-2367) [Gogo] Use org.apache.felix namespace to avoid any perceived legal issues
[Gogo] Use org.apache.felix namespace to avoid any perceived legal issues - Key: FELIX-2367 URL: https://issues.apache.org/jira/browse/FELIX-2367 Project: Felix Issue Type: Task Affects Versions: gogo-0.4.0 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: gogo-0.6.0 Currently, Gogo includes packages in the org.osgi namespace, but there are issues around doing so since the spec hasn't been officially released and since we are supposed to be driving the spec, we need to be able to openly make changes to these packages. Therefore, it is better to move everything into the org.apache.felix package namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Move Karaf as a TLP
On 5/28/10 10:16, Guillaume Nodet wrote: I think the Felix PMC needs to vote on the resolution that would be proposed to the board, at least that's what happened in the few subproject to tlp moved i've been involved in. However, i'd like to have the proposed resolution agreed on before starting a vote, as I don't see the need for two related votes. Sounds reasonable to me. - richard On Fri, May 28, 2010 at 15:30, Richard S. Hallhe...@ungoverned.org wrote: Question: Is a formal vote necessary to start this process or is our informal consensus enough? - richard On 5/28/10 1:40, Guillaume Nodet wrote: It seems there is a consensus to move Karaf as a TLP, at least amongst people involved in Karaf (the other felix committers haven't really expressed any opinion). I think the next steps would be to draft a proposed resolution to the board, which would include: * the project goal * the project PMC (including the chair) In order to create an open community from the start, I'd like to invite anyone with an Apache account willing to contribute to Karaf to raise hands so that we can build this list. I don't think opening it wider for now would be wise, but I do thing we should have a very low entry bar for committership (but that can be discussed later). I'll try to come up with a proposal for Karaf's project goal asap, but anyone is welcome to give it a try and propose some wording. FWIW, it would like the following, we just need to fill the : WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a machine learning platform for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Karaf Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Karaf Project be and hereby is responsible for the creation and maintenance of software related to XXX; and be it further RESOLVED, that the office of Vice President, Apache Karaf be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Karaf Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Karaf Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Karaf Project: * ...@apache.org * ... NOW, THEREFORE, BE IT FURTHER RESOLVED, that X be appointed to the office of Vice President, Apache Karaf, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Karaf PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Mahout Project; and be it further RESOLVED, that the Apache Karaf Project be and hereby is tasked with the migration and rationalization of the Apache Felix Karaf sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Felix Karaf sub-project encumbered upon the Apache Felix Project are hereafter discharged. On Fri, May 14, 2010 at 12:20, Guillaume Nodetgno...@gmail.com wrote: Karaf has been brought into the Felix TLP nearly one year ago. Things have not been too bad, but I still see the karaf community as being very disjoint from the other felix community, as it looks that none of the existing felix committers did really get involved in Karaf. I really don't blame anyone, i think it's just that the interest are not the same (not sure where they actually diverge though). I don't really see what benefit Karaf would have in continuing being part of Felix, so I'd like to open the discussion about moving it to a TLP. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Resolved: (FELIX-2337) [gogo] no way to access array[] elements produced by assignment
[
https://issues.apache.org/jira/browse/FELIX-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Baum resolved FELIX-2337.
---
Resolution: Fixed
This has been fixed by not automatically converting return values that are
Array[] into ArrayList.
If you want to explicitly convert an Array[] into an List, then use:
g! b = (bundles)
g! lb = [ $b ]
g! set lb
ArrayList lb [org.apache.felix.framework [0], org.apache.f...
g! set b
Bundle[]b [Lorg.osgi.framework.Bundle;@538f1d7e
g!
To access elements of an array or list, use:
g! $b 1
Location
file:/Users/derek/Downloads/felix-framework-2.0.4/bundle/org.apache.felix.gogo.command-0.5.0-SNAPSHOT.jar
...
or
g! $lb get 1
Location
file:/Users/derek/Downloads/felix-framework-2.0.4/bundle/org.apache.felix.gogo.command-0.5.0-SNAPSHOT.jar
...
[gogo] no way to access array[] elements produced by assignment
---
Key: FELIX-2337
URL: https://issues.apache.org/jira/browse/FELIX-2337
Project: Felix
Issue Type: Bug
Components: Gogo
Reporter: Derek Baum
Assignee: Derek Baum
Priority: Minor
Fix For: gogo-0.6.0
the following two alternative assignments, should be equivalent:
x = command args ...
x = (command args ..)
but they are not, if the result is an array:
% x = [a b c] toarray
% $x get 0
IllegalArgumentException: Cannot coerce get[0] to any of []
% x = ([a b c] toarray)
% $x get 0
This is because gogo normally converts any array result into a list
(Closure.java:228):
if (last.result instanceof Object[])
{
return Arrays.asList((Object[]) last.result);
}
but the assignment without () bypasses this conversion, and results in a real
array.
I can obviously fix this so that the conversion to a List occurs in all
cases, but I was wondering whether gogo should be performing this conversion
in the first place? If the conversion is not performed, then we'll need to
support ($array $index) to access arrays.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Framework release coming soon
This solution seems to work OK.
I've just committed it as the fix for FELIX-2337.
Derek
On 28 May 2010 12:59, Derek Baum derek.b...@paremus.com wrote:
yes.
Currently gogo converts any array result into a list (Closure.java:228):
if (last.result instanceof Object[])
{
return Arrays.asList((Object[]) last.result);
}
If it didn't do this, then
g! headers (bundles)
will work directly with any extra coercion being needed.
We would also need to allow a method to access arrays:
b = (bundles)
b1 = $b 1
(currently this is 'b1 = $b get 1', because b is converted to an array
list).
I'll test this locally, to check it doesn't break the tests or have any
obvious bad side effects.
Derek
On 28 May 2010 00:39, Richard S. Hall he...@ungoverned.org wrote:
Do you have a suggestion for a quick fix before we try to release?
The plan was to cut a release on Sunday...
- richard
On 5/27/10 7:33 PM, Derek Baum wrote:
Further investigation shows:
g! type bundles
bundles is Bundle[] context:bundles()
true
g! type headers
headers is void felix:headers(Bundle[])
true
// so bundles appears to return the Bundle[] type required by the headers
command
g! b = (bundles)
0|Active |0|org.apache.felix.framework (2.0.4)
1|Active |1|org.apache.felix.gogo.command (0.5.0.SNAPSHOT)
2|Active |1|org.apache.felix.gogo.runtime (0.5.0.SNAPSHOT)
3|Active |1|org.apache.felix.gogo.shell (0.5.0.SNAPSHOT)
g! set b
ArrayList b [org.apache.felix.framework [0],
org.apache.f...
// but the result is actually converted into an ArrayList
// and the current coercion mechanism is failing to convert the ArrayList
back to the required Array[]
// explicit conversion works, but should not be necessary:
g! ba = $b toarray
0|Active |0|org.apache.felix.framework (2.0.4)
1|Active |1|org.apache.felix.gogo.command (0.5.0.SNAPSHOT)
2|Active |1|org.apache.felix.gogo.runtime (0.5.0.SNAPSHOT)
3|Active |1|org.apache.felix.gogo.shell (0.5.0.SNAPSHOT)
g! set ba
Bundle[]ba [Lorg.osgi.framework.Bundle;@67d225a7
g! headers $ba
System Bundle (0)
-
Bundle-Description = This bundle is system specific; it implements
various
system services.
// etc
Note: https://issues.apache.org/jira/browse/FELIX-2337 is also related
to
this, as
x = command args
can set x to an array[], while
x = (command args)
will always convert the result to an ArrayList.
ArrayLists are undoubtedly more useful, but I wonder whether array[]
results should be automatically converted to ArrayLists, rather than just
coerced as needed, like any other type.
Derek
On 28 May 2010 00:12, Richard S. Hallhe...@ungoverned.org wrote:
On 5/27/10 7:10 PM, Guillaume Nodet wrote:
It seems the new coercion mechanism is a bit flawed:
g! headers (bundles)
gogo: IllegalArgumentException: Cannot coerce
headers[[org.apache.felix.framework [0],
org.apache.felix.bundlerepository
[1], org.apache.felix.gogo.command [2], org.apache.felix.gogo.runtime
[3],
org.apache.felix.gogo.shell [4]]] to any of [(Bundle[])]
That should work without problems. The coercer needs to be enhacned
with
the
following code:
http://svn.apache.org/repos/asf/felix/trunk/gogo/commands/src/main/java/org/apache/felix/gogo/commands/converter/DefaultConverter.java
Thanks. I will try to look into it tomorrow.
- richard
On Thu, May 27, 2010 at 20:49, Richard S. Hallhe...@ungoverned.org
wrote:
So, we are gearing up to release the 3.0 version of the framework. As
part
of this release, we're going to include Gogo as the default shell in
the
framework binary distribution. Gogo requires Java 5 or later, but
don't
worry, the framework still targets lesser JREs. :-)
I've uploaded a snapshot of the distribution in tar.gz and zip if
anyone
wants to play with it:
https://repository.apache.org/content/groups/snapshots-group/org/apache/felix/org.apache.felix.main.distribution/2.1.0-SNAPSHOT/
Word of warning, the ps command has been renamed to lb (i.e., list
bundles)...type help to see available commands.
- richard
Re: Framework release coming soon
On 5/27/10 20:25, Guillaume Nodet wrote: FWIW, I've just made a few commits to the framework resolver. The three first commits are actually just code cleanup (missing generics annotations, removing various warnings). The last one makes the resolver slightly more generic but does not change the behavior in any way. Those modifications will allow to reuse this new and shiny resolver inside OBR :-) I just went through them all and they looked ok. When it gets this late in the preparation of a release, it would probably be better to submit patches for consideration rather committing to trunk, since it could complicate the planned released. - richard On Thu, May 27, 2010 at 20:49, Richard S. Hallhe...@ungoverned.org wrote: So, we are gearing up to release the 3.0 version of the framework. As part of this release, we're going to include Gogo as the default shell in the framework binary distribution. Gogo requires Java 5 or later, but don't worry, the framework still targets lesser JREs. :-) I've uploaded a snapshot of the distribution in tar.gz and zip if anyone wants to play with it: https://repository.apache.org/content/groups/snapshots-group/org/apache/felix/org.apache.felix.main.distribution/2.1.0-SNAPSHOT/ Word of warning, the ps command has been renamed to lb (i.e., list bundles)...type help to see available commands. - richard
Re: Framework release coming soon
On 5/28/10 10:35, Derek Baum wrote:
This solution seems to work OK.
I've just committed it as the fix for FELIX-2337.
Great, thanks!
- richard
Derek
On 28 May 2010 12:59, Derek Baumderek.b...@paremus.com wrote:
yes.
Currently gogo converts any array result into a list (Closure.java:228):
if (last.result instanceof Object[])
{
return Arrays.asList((Object[]) last.result);
}
If it didn't do this, then
g! headers (bundles)
will work directly with any extra coercion being needed.
We would also need to allow a method to access arrays:
b = (bundles)
b1 = $b 1
(currently this is 'b1 = $b get 1', because b is converted to an array
list).
I'll test this locally, to check it doesn't break the tests or have any
obvious bad side effects.
Derek
On 28 May 2010 00:39, Richard S. Hallhe...@ungoverned.org wrote:
Do you have a suggestion for a quick fix before we try to release?
The plan was to cut a release on Sunday...
- richard
On 5/27/10 7:33 PM, Derek Baum wrote:
Further investigation shows:
g! type bundles
bundles is Bundle[] context:bundles()
true
g! type headers
headers is void felix:headers(Bundle[])
true
// so bundles appears to return the Bundle[] type required by the headers
command
g! b = (bundles)
0|Active |0|org.apache.felix.framework (2.0.4)
1|Active |1|org.apache.felix.gogo.command (0.5.0.SNAPSHOT)
2|Active |1|org.apache.felix.gogo.runtime (0.5.0.SNAPSHOT)
3|Active |1|org.apache.felix.gogo.shell (0.5.0.SNAPSHOT)
g! set b
ArrayList b [org.apache.felix.framework [0],
org.apache.f...
// but the result is actually converted into an ArrayList
// and the current coercion mechanism is failing to convert the ArrayList
back to the required Array[]
// explicit conversion works, but should not be necessary:
g! ba = $b toarray
0|Active |0|org.apache.felix.framework (2.0.4)
1|Active |1|org.apache.felix.gogo.command (0.5.0.SNAPSHOT)
2|Active |1|org.apache.felix.gogo.runtime (0.5.0.SNAPSHOT)
3|Active |1|org.apache.felix.gogo.shell (0.5.0.SNAPSHOT)
g! set ba
Bundle[]ba [Lorg.osgi.framework.Bundle;@67d225a7
g! headers $ba
System Bundle (0)
-
Bundle-Description = This bundle is system specific; it implements
various
system services.
// etc
Note: https://issues.apache.org/jira/browse/FELIX-2337 is also related
to
this, as
x = command args
can set x to an array[], while
x = (command args)
will always convert the result to an ArrayList.
ArrayLists are undoubtedly more useful, but I wonder whether array[]
results should be automatically converted to ArrayLists, rather than just
coerced as needed, like any other type.
Derek
On 28 May 2010 00:12, Richard S. Hallhe...@ungoverned.org wrote:
On 5/27/10 7:10 PM, Guillaume Nodet wrote:
It seems the new coercion mechanism is a bit flawed:
g! headers (bundles)
gogo: IllegalArgumentException: Cannot coerce
headers[[org.apache.felix.framework [0],
org.apache.felix.bundlerepository
[1], org.apache.felix.gogo.command [2], org.apache.felix.gogo.runtime
[3],
org.apache.felix.gogo.shell [4]]] to any of [(Bundle[])]
That should work without problems. The coercer needs to be enhacned
with
the
following code:
http://svn.apache.org/repos/asf/felix/trunk/gogo/commands/src/main/java/org/apache/felix/gogo/commands/converter/DefaultConverter.java
Thanks. I will try to look into it tomorrow.
- richard
On Thu, May 27, 2010 at 20:49, Richard S. Hallhe...@ungoverned.org
wrote:
So, we are gearing up to release the 3.0 version of the framework. As
part
of this release, we're going to include Gogo as the default shell in
the
framework binary distribution. Gogo requires Java 5 or later, but
don't
worry, the framework still targets lesser JREs. :-)
I've uploaded a snapshot of the distribution in tar.gz and zip if
anyone
wants to play with it:
https://repository.apache.org/content/groups/snapshots-group/org/apache/felix/org.apache.felix.main.distribution/2.1.0-SNAPSHOT/
Word of warning, the ps command has been renamed to lb (i.e., list
bundles)...type help to see available commands.
-richard
[jira] Closed: (FELIX-2367) [Gogo] Use org.apache.felix namespace to avoid any perceived legal issues
[ https://issues.apache.org/jira/browse/FELIX-2367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-2367. -- Resolution: Fixed Packages have been renamed to avoid issues associated with using the org.osgi package namespace. [Gogo] Use org.apache.felix namespace to avoid any perceived legal issues - Key: FELIX-2367 URL: https://issues.apache.org/jira/browse/FELIX-2367 Project: Felix Issue Type: Task Affects Versions: gogo-0.4.0 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: gogo-0.6.0 Currently, Gogo includes packages in the org.osgi namespace, but there are issues around doing so since the spec hasn't been officially released and since we are supposed to be driving the spec, we need to be able to openly make changes to these packages. Therefore, it is better to move everything into the org.apache.felix package namespace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [DISCUSS] Move Karaf as a TLP
I would like to be involved with this TLP as well. Thanks, Jarek On Friday, May 28, 2010, Guillaume Nodet gno...@gmail.com wrote: It seems there is a consensus to move Karaf as a TLP, at least amongst people involved in Karaf (the other felix committers haven't really expressed any opinion). I think the next steps would be to draft a proposed resolution to the board, which would include: * the project goal * the project PMC (including the chair) In order to create an open community from the start, I'd like to invite anyone with an Apache account willing to contribute to Karaf to raise hands so that we can build this list. I don't think opening it wider for now would be wise, but I do thing we should have a very low entry bar for committership (but that can be discussed later). I'll try to come up with a proposal for Karaf's project goal asap, but anyone is welcome to give it a try and propose some wording. FWIW, it would like the following, we just need to fill the : WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software related to a machine learning platform for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Karaf Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Karaf Project be and hereby is responsible for the creation and maintenance of software related to XXX; and be it further RESOLVED, that the office of Vice President, Apache Karaf be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Karaf Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Karaf Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Karaf Project: * xxx x...@apache.org * ... NOW, THEREFORE, BE IT FURTHER RESOLVED, that X be appointed to the office of Vice President, Apache Karaf, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the initial Apache Karaf PMC be and hereby is tasked with the creation of a set of bylaws intended to encourage open development and increased participation in the Apache Mahout Project; and be it further RESOLVED, that the Apache Karaf Project be and hereby is tasked with the migration and rationalization of the Apache Felix Karaf sub-project; and be it further RESOLVED, that all responsibilities pertaining to the Apache Felix Karaf sub-project encumbered upon the Apache Felix Project are hereafter discharged. On Fri, May 14, 2010 at 12:20, Guillaume Nodet gno...@gmail.com wrote: Karaf has been brought into the Felix TLP nearly one year ago. Things have not been too bad, but I still see the karaf community as being very disjoint from the other felix community, as it looks that none of the existing felix committers did really get involved in Karaf. I really don't blame anyone, i think it's just that the interest are not the same (not sure where they actually diverge though). I don't really see what benefit Karaf would have in continuing being part of Felix, so I'd like to open the discussion about moving it to a TLP. -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Closed: (FELIX-2035) Reimplement framework resolver
[ https://issues.apache.org/jira/browse/FELIX-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-2035. -- Resolution: Fixed Closing this in preparation for the 3.0. Any future resolver issues should be opened as new JIRA issues. Reimplement framework resolver -- Key: FELIX-2035 URL: https://issues.apache.org/jira/browse/FELIX-2035 Project: Felix Issue Type: Improvement Components: Framework Affects Versions: framework-2.0.3 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: framework-3.0.0 The current framework resolver is functional, but there are scenarios that cause it to go into apparent endless conflict detection and resolution cycles. We need to introduce an algorithm that is a little bit smarter in how it searches for solutions. Additionally, the design could be improved. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-2036) Improve resolver's generic capability/requirement model
[ https://issues.apache.org/jira/browse/FELIX-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-2036. -- Resolution: Fixed Closing this in preparation for the 3.0. Any future resolver issues should be opened as new JIRA issues. Improve resolver's generic capability/requirement model --- Key: FELIX-2036 URL: https://issues.apache.org/jira/browse/FELIX-2036 Project: Felix Issue Type: Sub-task Components: Framework Affects Versions: framework-2.0.3 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: framework-3.0.0 The current resolver uses a generic capability/requirement model, but it sometimes has to peek under the covers to improve efficiency. The approach needs to be improved to support capability indexing and quick matching of requirements. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (FELIX-2037) Improve resolver performance by making solution space searching smarter
[ https://issues.apache.org/jira/browse/FELIX-2037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard S. Hall closed FELIX-2037. -- Resolution: Fixed Closing this in preparation for the 3.0. Any future resolver issues should be opened as new JIRA issues. Improve resolver performance by making solution space searching smarter --- Key: FELIX-2037 URL: https://issues.apache.org/jira/browse/FELIX-2037 Project: Felix Issue Type: Sub-task Components: Framework Affects Versions: framework-2.0.3 Reporter: Richard S. Hall Assignee: Richard S. Hall Fix For: framework-3.0.0 The main performance issue with the current resolver algorithm is when a conflict is detected, it largely just blindly permutates to the next available possibility without trying to determine which possibility makes more sense. We need to make this smarter without losing the ability to check all/most viable solutions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2368) Activate components synchronously
Activate components synchronously - Key: FELIX-2368 URL: https://issues.apache.org/jira/browse/FELIX-2368 Project: Felix Issue Type: Improvement Components: Declarative Services (SCR) Affects Versions: scr-1.4.0 Reporter: Felix Meschberger Assignee: Felix Meschberger Fix For: scr-1.4.2 Currently components are activated asynchronously. This works perfect but adds delay to startup sequences. An additional problem is that on system startup once the FRAMEWORK_STARTED event is received, SCR is still busy activating components. This creates a problem if we want to decide on the actual system state. Conversely, disposal (and disabling) of components always takes place immediately, because either a required dependency is about to go away or the providing bundle is stopped. In the first case asynchronous disabling will lead to problems because of unavailable services and the second case might cause IllegalStateExceptions if the BundleContext is accessed after the bundle has been stopped. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2150) URLStreamHandlerProxy.setURL may not set query component correctly
[
https://issues.apache.org/jira/browse/FELIX-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-2150:
--
Fix Version/s: framework-3.0.0
Affects Version/s: framework-2.0.5
Include this in 3.0
URLStreamHandlerProxy.setURL may not set query component correctly
--
Key: FELIX-2150
URL: https://issues.apache.org/jira/browse/FELIX-2150
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-2.0.4, framework-2.0.5
Reporter: Sahoo
Assignee: Karl Pauls
Fix For: framework-3.0.0
On Mon, Mar 1, 2010 at 12:56 PM, Sahoo sa...@sun.com wrote:
Hi,
org.apache.felix.framework.URLStreamHandlerProxy has following methods:
public void setURL(
URL url, String protocol, String host, int port, String authority,
String userInfo, String path, String query, String ref)
{
super.setURL(url, protocol, host, port, authority, userInfo, path,
query, ref);
}
public void setURL(
URL url, String protocol, String host, int port, String file, String
ref)
{
super.setURL(url, protocol, host, port, null, null, file, null,
ref);
}
There appears to be a *bug* in the latter method. It passes file as
path. Should file not be brone into path and query components which
would
have automatically happened if
super.setURL(url, protocol, host, port, file, ref) been called? Any
comments? I have not done any testing, just concluding based on code
inspection.
I agree, looks like a bug. It is not as bad as the path can be the
file as well but if you would call getQuery() on the resulting url it
will return null i think (even if you had a query). Could you create a
jira for this?
Thanks and regards,
Karl
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2150) URLStreamHandlerProxy.setURL may not set query component correctly
[
https://issues.apache.org/jira/browse/FELIX-2150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls resolved FELIX-2150.
---
Resolution: Fixed
I changed it to use the correct super method. Thanks.
URLStreamHandlerProxy.setURL may not set query component correctly
--
Key: FELIX-2150
URL: https://issues.apache.org/jira/browse/FELIX-2150
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-2.0.4, framework-2.0.5
Reporter: Sahoo
Assignee: Karl Pauls
Fix For: framework-3.0.0
On Mon, Mar 1, 2010 at 12:56 PM, Sahoo sa...@sun.com wrote:
Hi,
org.apache.felix.framework.URLStreamHandlerProxy has following methods:
public void setURL(
URL url, String protocol, String host, int port, String authority,
String userInfo, String path, String query, String ref)
{
super.setURL(url, protocol, host, port, authority, userInfo, path,
query, ref);
}
public void setURL(
URL url, String protocol, String host, int port, String file, String
ref)
{
super.setURL(url, protocol, host, port, null, null, file, null,
ref);
}
There appears to be a *bug* in the latter method. It passes file as
path. Should file not be brone into path and query components which
would
have automatically happened if
super.setURL(url, protocol, host, port, file, ref) been called? Any
comments? I have not done any testing, just concluding based on code
inspection.
I agree, looks like a bug. It is not as bad as the path can be the
file as well but if you would call getQuery() on the resulting url it
will return null i think (even if you had a query). Could you create a
jira for this?
Thanks and regards,
Karl
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2356) extension bundle cannot load class from embed jar
[ https://issues.apache.org/jira/browse/FELIX-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Pauls resolved FELIX-2356. --- Resolution: Fixed Fixed in trunk. This will be part of the upcomming 3.0 release. Thanks. extension bundle cannot load class from embed jar - Key: FELIX-2356 URL: https://issues.apache.org/jira/browse/FELIX-2356 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-2.0.5 Environment: Window XP, JDK-1.5, maven-2.2.1 Reporter: Xu Hui Sheng Assignee: Karl Pauls Fix For: framework-3.0.0 Attachments: mavensample.zip I try to use extension bundle to export additional package. These additional package should put into the extension bundle. If I put these package inline the extension bundle, then everything is all right. If I put these package as embed jar and refer the embed jar from Bundle-ClassPath, then the other bundle cannot find these package. I will get ClassNotException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2356) extension bundle cannot load class from embed jar
[ https://issues.apache.org/jira/browse/FELIX-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12873216#action_12873216 ] Xu Hui Sheng commented on FELIX-2356: - Thank you very much. Where could I get the SNAPSHOT of current trunk? I want to have a try. Thanks again. extension bundle cannot load class from embed jar - Key: FELIX-2356 URL: https://issues.apache.org/jira/browse/FELIX-2356 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-2.0.5 Environment: Window XP, JDK-1.5, maven-2.2.1 Reporter: Xu Hui Sheng Assignee: Karl Pauls Fix For: framework-3.0.0 Attachments: mavensample.zip I try to use extension bundle to export additional package. These additional package should put into the extension bundle. If I put these package inline the extension bundle, then everything is all right. If I put these package as embed jar and refer the embed jar from Bundle-ClassPath, then the other bundle cannot find these package. I will get ClassNotException. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
