[jira] Updated: (FELIX-2372) Improve logging on IllegalStateException getting a service
[ https://issues.apache.org/jira/browse/FELIX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-2372: - Description: BundleContext.getService() may throw an IllegalStateException if the bundle context is invalid. In addition the Felix implementation may also throw this exception of the service to be trieved is a ServiceFactory whose real service cannot be retrieved due to a cycle in service dependencies. The DependencyManager should log this exception clearly to help solve the actual problem. In the current Felix Declarative Service implementation such a loop can be created if there is a depedency loop amongst delayed service components, like this: Delayed Component A, provides Service A, requires Service C Delayed Component B, provides Service B, requires Service A Delayed Component C, provides Service C, requires Service B Such cycles should actually be detected by SCR (Declarative Services Specification Section 112.3.5, Circular References), but this is not currently implemented, see FELIX-1824. Still, such cycles may of course exist amongst services registered outside of the Declarative Services world, in which case, such an exception may still occur. was: BundleContext.getService() may throw an IllegalStateException if the bundle context is invalid. In addition the Felix implementation may also throw this exception of the service to be trieved is a ServiceFactory whose real service cannot be retrieved due to a cycle in service dependencies. The DependencyManager should log this exception clearly to help solve the actual problem. In the current Felix Declarative Service implementation such a loop can be created if there is a depedency loop amongst delayed service components, like this: Delayed Component A, provides Service A, requires Service C Delayed Component B, provides Service B, requires Service A Delayed Component C, provides Service C, requires Service B Improve logging on IllegalStateException getting a service -- Key: FELIX-2372 URL: https://issues.apache.org/jira/browse/FELIX-2372 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 BundleContext.getService() may throw an IllegalStateException if the bundle context is invalid. In addition the Felix implementation may also throw this exception of the service to be trieved is a ServiceFactory whose real service cannot be retrieved due to a cycle in service dependencies. The DependencyManager should log this exception clearly to help solve the actual problem. In the current Felix Declarative Service implementation such a loop can be created if there is a depedency loop amongst delayed service components, like this: Delayed Component A, provides Service A, requires Service C Delayed Component B, provides Service B, requires Service A Delayed Component C, provides Service C, requires Service B Such cycles should actually be detected by SCR (Declarative Services Specification Section 112.3.5, Circular References), but this is not currently implemented, see FELIX-1824. Still, such cycles may of course exist amongst services registered outside of the Declarative Services world, in which case, such an exception may still occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (FELIX-2372) Improve logging on IllegalStateException getting a service
[ https://issues.apache.org/jira/browse/FELIX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12873564#action_12873564 ] Felix Meschberger commented on FELIX-2372: -- Such cycles should actually be detected by SCR (Declarative Services Specification Section 112.3.5, Circular References), but this is not currently implemented, see FELIX-1824. Improve logging on IllegalStateException getting a service -- Key: FELIX-2372 URL: https://issues.apache.org/jira/browse/FELIX-2372 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 BundleContext.getService() may throw an IllegalStateException if the bundle context is invalid. In addition the Felix implementation may also throw this exception of the service to be trieved is a ServiceFactory whose real service cannot be retrieved due to a cycle in service dependencies. The DependencyManager should log this exception clearly to help solve the actual problem. In the current Felix Declarative Service implementation such a loop can be created if there is a depedency loop amongst delayed service components, like this: Delayed Component A, provides Service A, requires Service C Delayed Component B, provides Service B, requires Service A Delayed Component C, provides Service C, requires Service B -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2372) Improve logging on IllegalStateException getting a service
[ https://issues.apache.org/jira/browse/FELIX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger updated FELIX-2372: - Comment: was deleted (was: Such cycles should actually be detected by SCR (Declarative Services Specification Section 112.3.5, Circular References), but this is not currently implemented, see FELIX-1824.) Improve logging on IllegalStateException getting a service -- Key: FELIX-2372 URL: https://issues.apache.org/jira/browse/FELIX-2372 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 BundleContext.getService() may throw an IllegalStateException if the bundle context is invalid. In addition the Felix implementation may also throw this exception of the service to be trieved is a ServiceFactory whose real service cannot be retrieved due to a cycle in service dependencies. The DependencyManager should log this exception clearly to help solve the actual problem. In the current Felix Declarative Service implementation such a loop can be created if there is a depedency loop amongst delayed service components, like this: Delayed Component A, provides Service A, requires Service C Delayed Component B, provides Service B, requires Service A Delayed Component C, provides Service C, requires Service B Such cycles should actually be detected by SCR (Declarative Services Specification Section 112.3.5, Circular References), but this is not currently implemented, see FELIX-1824. Still, such cycles may of course exist amongst services registered outside of the Declarative Services world, in which case, such an exception may still occur. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (FELIX-2372) Improve logging on IllegalStateException getting a service
[ https://issues.apache.org/jira/browse/FELIX-2372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger resolved FELIX-2372. -- Resolution: Fixed Fixed in Rev. 949675. Improve logging on IllegalStateException getting a service -- Key: FELIX-2372 URL: https://issues.apache.org/jira/browse/FELIX-2372 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 BundleContext.getService() may throw an IllegalStateException if the bundle context is invalid. In addition the Felix implementation may also throw this exception of the service to be trieved is a ServiceFactory whose real service cannot be retrieved due to a cycle in service dependencies. The DependencyManager should log this exception clearly to help solve the actual problem. In the current Felix Declarative Service implementation such a loop can be created if there is a depedency loop amongst delayed service components, like this: Delayed Component A, provides Service A, requires Service C Delayed Component B, provides Service B, requires Service A Delayed Component C, provides Service C, requires Service B Such cycles should actually be detected by SCR (Declarative Services Specification Section 112.3.5, Circular References), but this is not currently implemented, see FELIX-1824. Still, such cycles may of course exist amongst services registered outside of the Declarative Services world, in which case, such an exception may still occur. -- 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
L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki luk...@dywicki.pl wrote: I would like to say 'yes' for TLP (even if my vote doesn't count). I try contribute Karaf from time to time and I wish continue doing that, when it will move to top level too. For me it does not make sense to try close all OSGi releated things in Felix project. At this moment we have Aries which is also very closer to OSGi but it's not a part of Felix. Best regards, Lukasz Dywicki Jarek Gawor-2 wrote: 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
[jira] Created: (FELIX-2373) Wrapper service is not configured properly in Karaf 1.6.0
Wrapper service is not configured properly in Karaf 1.6.0 - Key: FELIX-2373 URL: https://issues.apache.org/jira/browse/FELIX-2373 Project: Felix Issue Type: Bug Components: Karaf Affects Versions: karaf 1.6.0 Reporter: Bengt Rodehav Changes related to Karaf startup has been done in Karaf 1.6.0 but those changes have not been reflected in the configuration of the Wrapper service. I had to do the following changes in karaf-wrapper.conf to get Karaf 1.6.0 to work with the Wrapper service: a) Change the main class: wrapper.app.parameter.1=org.apache.felix.karaf.main.Main b) Add the following line to the classpath: wrapper.java.classpath.4=%KARAF_HOME%/system/org/apache/felix/org.apache.felix.framework/2.0.5/org.apache.felix.framework-2.0.5.jar c) Add the following JVM parameters: wrapper.java.additional.6=-Djava.endorsed.dirs=%JAVA_HOME%/lib/endorsed;%KARAF_HOME%/lib/endorsed wrapper.java.additional.7=-Djava.ext.dirs=%JAVA_HOME%/lib/ext;%KARAF_HOME%/lib/ext Actually c) wasn't really necessary to get Karaf started but it seemed to have been omitted in comparison to karaf.bat. Overall I think someone should compare the settings in karaf.bat with the ones in karaf-wrapper.conf to make sure they are the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (FELIX-2374) Configuration param for the output dir of the bundleall goal
Configuration param for the output dir of the bundleall goal Key: FELIX-2374 URL: https://issues.apache.org/jira/browse/FELIX-2374 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.0.1 Reporter: Henrik Niehaus Priority: Minor Fix For: maven-bundle-plugin-2.1.0 I needed a possibility to set the output directory of the bundleall goal to another directory as the build.outputDirectory. So here is a patch, which introduces the config param bundleallOutputDirectory. It is an optional parameter, which defaults to build.outputDirectory, so the change is fully backwards compatible. Would be great, if future versions would include this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (FELIX-2374) Configuration param for the output dir of the bundleall goal
[ https://issues.apache.org/jira/browse/FELIX-2374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrik Niehaus updated FELIX-2374: -- Attachment: bundle_all_output_dir.diff Configuration param for the output dir of the bundleall goal Key: FELIX-2374 URL: https://issues.apache.org/jira/browse/FELIX-2374 Project: Felix Issue Type: Improvement Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.0.1 Reporter: Henrik Niehaus Priority: Minor Fix For: maven-bundle-plugin-2.1.0 Attachments: bundle_all_output_dir.diff I needed a possibility to set the output directory of the bundleall goal to another directory as the build.outputDirectory. So here is a patch, which introduces the config param bundleallOutputDirectory. It is an optional parameter, which defaults to build.outputDirectory, so the change is fully backwards compatible. Would be great, if future versions would include this patch. -- 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 Mon, May 31, 2010 at 11:14, Gert Vanthienen gert.vanthie...@gmail.comwrote: L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications Well, it actually looks perfect to me :-) Let's see what other people think about it. Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki luk...@dywicki.pl wrote: I would like to say 'yes' for TLP (even if my vote doesn't count). I try contribute Karaf from time to time and I wish continue doing that, when it will move to top level too. For me it does not make sense to try close all OSGi releated things in Felix project. At this moment we have Aries which is also very closer to OSGi but it's not a part of Felix. Best regards, Lukasz Dywicki Jarek Gawor-2 wrote: 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
Re: [DISCUSS] Move Karaf as a TLP
This sounds good to me too. It encompasses all the functions that the Karaf project will be continuing and/or expanding to do as a TLP. Jamie On Mon, May 31, 2010 at 11:17 AM, Guillaume Nodet gno...@gmail.com wrote: On Mon, May 31, 2010 at 11:14, Gert Vanthienen gert.vanthie...@gmail.comwrote: L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications Well, it actually looks perfect to me :-) Let's see what other people think about it. Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki luk...@dywicki.pl wrote: I would like to say 'yes' for TLP (even if my vote doesn't count). I try contribute Karaf from time to time and I wish continue doing that, when it will move to top level too. For me it does not make sense to try close all OSGi releated things in Felix project. At this moment we have Aries which is also very closer to OSGi but it's not a part of Felix. Best regards, Lukasz Dywicki Jarek Gawor-2 wrote: 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,
Re: [DISCUSS] Move Karaf as a TLP
Hi, Based on Gert text, here is what I propose : ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications -- ... for the creation and maintenance of an extensible and OSGI-based server runtime, capable of being a base framework for building enterprise server applications, as well as the necessary tools (command line, (secure) shell, provisioning and logging) and components to facilitate building, (perhaps we can also add deployment and management) of these applications. Remark : - if we use small as qualifier for the runtime, we should define what are the boundaries of the server. Question : - applications word should be clarified with examples as well as enterprise server applications to give a better idea of the scope (Will the server be a Web/EJB container, ...) ? - Do we have to mention that Karaf project will be developed in close cooperation with Apache Aries as a lot of features (Transaction, JPA, ...) of Aries will be part of the enterprise server application ? Kind regards, Charles Moulliard Senior Enterprise Architect (J2EE, .NET, SOA) Apache Camel/ServiceMix Committer *** - Blog : http://cmoulliard.blogspot.com - Twitter : http://twitter.com/cmoulliard - Linkedlin : http://www.linkedin.com/in/charlesmoulliard On Mon, May 31, 2010 at 3:47 PM, Guillaume Nodet gno...@gmail.com wrote: On Mon, May 31, 2010 at 11:14, Gert Vanthienen gert.vanthie...@gmail.comwrote: L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications Well, it actually looks perfect to me :-) Let's see what other people think about it. Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki luk...@dywicki.pl wrote: I would like to say 'yes' for TLP (even if my vote doesn't count). I try contribute Karaf from time to time and I wish continue doing that, when it will move to top level too. For me it does not make sense to try close all OSGi releated things in Felix project. At this moment we have Aries which is also very closer to OSGi but it's not a part of Felix. Best regards, Lukasz Dywicki Jarek Gawor-2 wrote: 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
Re: [DISCUSS] Move Karaf as a TLP
This should be a one sentence description of the project. The only purpose is to roughly define the scope. We don't want to be too broad or people won't understand what the project goal is, nor we would want to be too narrow and restrict the scope too much or be too specific. For example, Camel is described as an open-source integration framework based on known Enterprise Integration Pattern. Other examples are: CouchDB: ... implementing a distributed, fault-tolerant and schema-free document-oriented database Qpid: ... distributed messaging Abdera: ... a framework for building clients and servers for the Atom Publishing Protocol and other related technology I even think we could trim the description a bit. The fact that we want to provide tooling is simply for easing the use of karaf, so maybe something a bit shorter like: an OSGI-based runtime for building enterprise server applications That could be enough. We might want to add a bit more details, but not too much imo. On Mon, May 31, 2010 at 17:26, Charles Moulliard cmoulli...@gmail.com wrote: Hi, Based on Gert text, here is what I propose : ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications -- ... for the creation and maintenance of an extensible and OSGI-based server runtime, capable of being a base framework for building enterprise server applications, as well as the necessary tools (command line, (secure) shell, provisioning and logging) and components to facilitate building, (perhaps we can also add deployment and management) of these applications. Remark : - if we use small as qualifier for the runtime, we should define what are the boundaries of the server. Question : - applications word should be clarified with examples as well as enterprise server applications to give a better idea of the scope (Will the server be a Web/EJB container, ...) ? - Do we have to mention that Karaf project will be developed in close cooperation with Apache Aries as a lot of features (Transaction, JPA, ...) of Aries will be part of the enterprise server application ? Kind regards, Charles Moulliard Senior Enterprise Architect (J2EE, .NET, SOA) Apache Camel/ServiceMix Committer *** - Blog : http://cmoulliard.blogspot.com - Twitter : http://twitter.com/cmoulliard - Linkedlin : http://www.linkedin.com/in/charlesmoulliard On Mon, May 31, 2010 at 3:47 PM, Guillaume Nodet gno...@gmail.com wrote: On Mon, May 31, 2010 at 11:14, Gert Vanthienen gert.vanthie...@gmail.comwrote: L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications Well, it actually looks perfect to me :-) Let's see what other people think about it. Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki luk...@dywicki.pl wrote: I would like to say 'yes' for TLP (even if my vote doesn't count). I try contribute Karaf from time to time and I wish continue doing that, when it will move to top level too. For me it does not make sense to try close all OSGi releated things in Felix project. At this moment we have Aries which is also very closer to OSGi but it's not a part of Felix. Best regards, Lukasz Dywicki Jarek Gawor-2 wrote: 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
Re: [DISCUSS] Move Karaf as a TLP
On May 31, 2010, at 9:04 AM, Guillaume Nodet wrote: This should be a one sentence description of the project. The only purpose is to roughly define the scope. We don't want to be too broad or people won't understand what the project goal is, nor we would want to be too narrow and restrict the scope too much or be too specific. For example, Camel is described as an open-source integration framework based on known Enterprise Integration Pattern. Other examples are: CouchDB: ... implementing a distributed, fault-tolerant and schema-free document-oriented database Qpid: ... distributed messaging Abdera: ... a framework for building clients and servers for the Atom Publishing Protocol and other related technology I even think we could trim the description a bit. The fact that we want to provide tooling is simply for easing the use of karaf, so maybe something a bit shorter like: an OSGI-based runtime for building enterprise server applications That could be enough. We might want to add a bit more details, but not too much imo. I think shorter is better. I wonder if this would be better: an OSGI based runtime for assembling enterprise servers building usually implies compilation to me and I don't expect most users of karaf to have to do compilation to use it (rather than some other osgi framework) ServiceMix and Geronimo which I think of as servers are built on karaf. Server applications sort of implies to me that you need an additional server to run them on. thanks david jencks On Mon, May 31, 2010 at 17:26, Charles Moulliard cmoulli...@gmail.com wrote: Hi, Based on Gert text, here is what I propose : ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications -- ... for the creation and maintenance of an extensible and OSGI-based server runtime, capable of being a base framework for building enterprise server applications, as well as the necessary tools (command line, (secure) shell, provisioning and logging) and components to facilitate building, (perhaps we can also add deployment and management) of these applications. Remark : - if we use small as qualifier for the runtime, we should define what are the boundaries of the server. Question : - applications word should be clarified with examples as well as enterprise server applications to give a better idea of the scope (Will the server be a Web/EJB container, ...) ? - Do we have to mention that Karaf project will be developed in close cooperation with Apache Aries as a lot of features (Transaction, JPA, ...) of Aries will be part of the enterprise server application ? Kind regards, Charles Moulliard Senior Enterprise Architect (J2EE, .NET, SOA) Apache Camel/ServiceMix Committer *** - Blog : http://cmoulliard.blogspot.com - Twitter : http://twitter.com/cmoulliard - Linkedlin : http://www.linkedin.com/in/charlesmoulliard On Mon, May 31, 2010 at 3:47 PM, Guillaume Nodet gno...@gmail.com wrote: On Mon, May 31, 2010 at 11:14, Gert Vanthienen gert.vanthie...@gmail.comwrote: L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications Well, it actually looks perfect to me :-) Let's see what other people think about it. Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki luk...@dywicki.pl wrote: I would like to say 'yes' for TLP (even if my vote doesn't count). I try contribute Karaf from time to time and I wish continue doing that, when it will move to top level too. For me it does not make sense to try close all OSGi releated things in Felix project. At this moment we have Aries which is also very closer to OSGi but it's not a part of Felix. Best regards, Lukasz Dywicki Jarek Gawor-2 wrote: 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
Re: [DISCUSS] Move Karaf as a TLP
I like both David and Guillaume's shorter versions. I could accept either one. Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Felix :: http://felix.apache.org Apache Directory Server :: http://directory.apache.org On Mon, May 31, 2010 at 10:12 AM, David Jencks david_jen...@yahoo.comwrote: On May 31, 2010, at 9:04 AM, Guillaume Nodet wrote: This should be a one sentence description of the project. The only purpose is to roughly define the scope. We don't want to be too broad or people won't understand what the project goal is, nor we would want to be too narrow and restrict the scope too much or be too specific. For example, Camel is described as an open-source integration framework based on known Enterprise Integration Pattern. Other examples are: CouchDB: ... implementing a distributed, fault-tolerant and schema-free document-oriented database Qpid: ... distributed messaging Abdera: ... a framework for building clients and servers for the Atom Publishing Protocol and other related technology I even think we could trim the description a bit. The fact that we want to provide tooling is simply for easing the use of karaf, so maybe something a bit shorter like: an OSGI-based runtime for building enterprise server applications That could be enough. We might want to add a bit more details, but not too much imo. I think shorter is better. I wonder if this would be better: an OSGI based runtime for assembling enterprise servers building usually implies compilation to me and I don't expect most users of karaf to have to do compilation to use it (rather than some other osgi framework) ServiceMix and Geronimo which I think of as servers are built on karaf. Server applications sort of implies to me that you need an additional server to run them on. thanks david jencks On Mon, May 31, 2010 at 17:26, Charles Moulliard cmoulli...@gmail.com wrote: Hi, Based on Gert text, here is what I propose : ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications -- ... for the creation and maintenance of an extensible and OSGI-based server runtime, capable of being a base framework for building enterprise server applications, as well as the necessary tools (command line, (secure) shell, provisioning and logging) and components to facilitate building, (perhaps we can also add deployment and management) of these applications. Remark : - if we use small as qualifier for the runtime, we should define what are the boundaries of the server. Question : - applications word should be clarified with examples as well as enterprise server applications to give a better idea of the scope (Will the server be a Web/EJB container, ...) ? - Do we have to mention that Karaf project will be developed in close cooperation with Apache Aries as a lot of features (Transaction, JPA, ...) of Aries will be part of the enterprise server application ? Kind regards, Charles Moulliard Senior Enterprise Architect (J2EE, .NET, SOA) Apache Camel/ServiceMix Committer *** - Blog : http://cmoulliard.blogspot.com - Twitter : http://twitter.com/cmoulliard - Linkedlin : http://www.linkedin.com/in/charlesmoulliard On Mon, May 31, 2010 at 3:47 PM, Guillaume Nodet gno...@gmail.com wrote: On Mon, May 31, 2010 at 11:14, Gert Vanthienen gert.vanthie...@gmail.comwrote: L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications Well, it actually looks perfect to me :-) Let's see what other people think about it. Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki luk...@dywicki.pl wrote: I would like to say 'yes' for TLP (even if my vote doesn't count). I try contribute Karaf from time to time and I wish continue doing that, when it will move to top level too. For me it does not make sense to try close all OSGi releated things in Felix project. At this moment we have Aries which is also very closer to OSGi but it's not a part of Felix. Best
Re: [DISCUSS] Move Karaf as a TLP
I agree that build may be too compilation tainted ... Let's go for assembling then. On Mon, May 31, 2010 at 18:12, David Jencks david_jen...@yahoo.com wrote: On May 31, 2010, at 9:04 AM, Guillaume Nodet wrote: This should be a one sentence description of the project. The only purpose is to roughly define the scope. We don't want to be too broad or people won't understand what the project goal is, nor we would want to be too narrow and restrict the scope too much or be too specific. For example, Camel is described as an open-source integration framework based on known Enterprise Integration Pattern. Other examples are: CouchDB: ... implementing a distributed, fault-tolerant and schema-free document-oriented database Qpid: ... distributed messaging Abdera: ... a framework for building clients and servers for the Atom Publishing Protocol and other related technology I even think we could trim the description a bit. The fact that we want to provide tooling is simply for easing the use of karaf, so maybe something a bit shorter like: an OSGI-based runtime for building enterprise server applications That could be enough. We might want to add a bit more details, but not too much imo. I think shorter is better. I wonder if this would be better: an OSGI based runtime for assembling enterprise servers building usually implies compilation to me and I don't expect most users of karaf to have to do compilation to use it (rather than some other osgi framework) ServiceMix and Geronimo which I think of as servers are built on karaf. Server applications sort of implies to me that you need an additional server to run them on. thanks david jencks On Mon, May 31, 2010 at 17:26, Charles Moulliard cmoulli...@gmail.com wrote: Hi, Based on Gert text, here is what I propose : ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications -- ... for the creation and maintenance of an extensible and OSGI-based server runtime, capable of being a base framework for building enterprise server applications, as well as the necessary tools (command line, (secure) shell, provisioning and logging) and components to facilitate building, (perhaps we can also add deployment and management) of these applications. Remark : - if we use small as qualifier for the runtime, we should define what are the boundaries of the server. Question : - applications word should be clarified with examples as well as enterprise server applications to give a better idea of the scope (Will the server be a Web/EJB container, ...) ? - Do we have to mention that Karaf project will be developed in close cooperation with Apache Aries as a lot of features (Transaction, JPA, ...) of Aries will be part of the enterprise server application ? Kind regards, Charles Moulliard Senior Enterprise Architect (J2EE, .NET, SOA) Apache Camel/ServiceMix Committer *** - Blog : http://cmoulliard.blogspot.com - Twitter : http://twitter.com/cmoulliard - Linkedlin : http://www.linkedin.com/in/charlesmoulliard On Mon, May 31, 2010 at 3:47 PM, Guillaume Nodet gno...@gmail.com wrote: On Mon, May 31, 2010 at 11:14, Gert Vanthienen gert.vanthie...@gmail.comwrote: L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications Well, it actually looks perfect to me :-) Let's see what other people think about it. Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki luk...@dywicki.pl wrote: I would like to say 'yes' for TLP (even if my vote doesn't count). I try contribute Karaf from time to time and I wish continue doing that, when it will move to top level too. For me it does not make sense to try close all OSGi releated things in Felix project. At this moment we have Aries which is also very closer to OSGi but it's not a part of Felix. Best regards, Lukasz Dywicki Jarek Gawor-2 wrote: 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
Re: Karaf 1.6.0 and ssh problem
I'll try to investigate. Maybe you should raise a JIRA issue. On Thu, May 27, 2010 at 16:41, HERKEL Jakub j.her...@cpce.net wrote: Is there any problem with ssh console in the latest version of Karaf (1.6.0)? I cannot connect to karaf and in log I can see an exception from sshd (see below). I have tried it from Windows (Putty) and also Fedora (ssh), but I have received the same exception. Is there a bug? 27.5.2010 15:58:41 org.apache.felix.karaf.main.SimpleFileLock lock INFO: locking 15:58:42,688 | INFO | FelixStartLevel | jmx | ? ? | 29 - org.apache.aries.jmx - 0.1.0.incubating | Starting JMX OSGi agent 15:58:42,781 | INFO | FelixStartLevel | jmx | ? ? | 29 - org.apache.aries.jmx - 0.1.0.incubating | Registering MBean with ObjectName [osgi.compendium:service=cm,version=1.3] for service with service.id [10] 15:58:43,912 | WARN | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 252 | 8 - org.apache.aries.blueprint - 0.1.0.incubating | Bundle org.apache.felix.karaf.shell.ssh is waiting for namespace handlers [((objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.servic e.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint- ext/v1.0.0) http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0%29 ), ((objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service .blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint-c m/v1.0.0) http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.0.0%29 ), ((objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service .blueprint.namespace=http://felix.apache.org/karaf/xmlns/shell/v1.0.0) http://felix.apache.org/karaf/xmlns/shell/v1.0.0%29 )] 15:58:43,912 | WARN | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 252 | 8 - org.apache.aries.blueprint - 0.1.0.incubating | Bundle org.apache.felix.karaf.shell.dev is waiting for namespace handlers [((objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.servic e.blueprint.namespace=http://felix.apache.org/karaf/xmlns/shell/v1.0.0) http://felix.apache.org/karaf/xmlns/shell/v1.0.0%29 )] 15:58:44,005 | WARN | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 252 | 8 - org.apache.aries.blueprint - 0.1.0.incubating | Bundle org.apache.felix.karaf.jaas.modules is waiting for namespace handlers [((objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.servic e.blueprint.namespace=http://aries.apache.org/blueprint/xmlns/blueprint- ext/v1.0.0) http://aries.apache.org/blueprint/xmlns/blueprint-ext/v1.0.0%29 ), ((objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.service .blueprint.namespace=http://felix.apache.org/karaf/xmlns/jaas/v1.0.0) http://felix.apache.org/karaf/xmlns/jaas/v1.0.0%29 )] 15:58:44,005 | WARN | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 252 | 8 - org.apache.aries.blueprint - 0.1.0.incubating | Bundle org.apache.felix.karaf.admin.command is waiting for namespace handlers [((objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.servic e.blueprint.namespace=http://felix.apache.org/karaf/xmlns/shell/v1.0.0) http://felix.apache.org/karaf/xmlns/shell/v1.0.0%29 )] 15:58:44,222 | WARN | rint Extender: 1 | BlueprintContainerImpl | container.BlueprintContainerImpl 252 | 8 - org.apache.aries.blueprint - 0.1.0.incubating | Bundle org.apache.felix.karaf.shell.osgi is waiting for namespace handlers [((objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.servic e.blueprint.namespace=http://felix.apache.org/karaf/xmlns/shell/v1.0.0) http://felix.apache.org/karaf/xmlns/shell/v1.0.0%29 )] 15:58:44,222 | WARN | rint Extender: 2 | BlueprintContainerImpl | container.BlueprintContainerImpl 252 | 8 - org.apache.aries.blueprint - 0.1.0.incubating | Bundle org.apache.felix.karaf.shell.commands is waiting for namespace handlers [((objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.servic e.blueprint.namespace=http://felix.apache.org/karaf/xmlns/shell/v1.0.0) http://felix.apache.org/karaf/xmlns/shell/v1.0.0%29 )] 15:58:44,238 | WARN | rint Extender: 1 | BlueprintContainerImpl | container.BlueprintContainerImpl 252 | 8 - org.apache.aries.blueprint - 0.1.0.incubating | Bundle org.apache.felix.karaf.shell.packages is waiting for namespace handlers [((objectClass=org.apache.aries.blueprint.NamespaceHandler)(osgi.servic e.blueprint.namespace=http://felix.apache.org/karaf/xmlns/shell/v1.0.0) http://felix.apache.org/karaf/xmlns/shell/v1.0.0%29 )] 15:58:45,044 | INFO | Thread-5 | FeaturesServiceImpl | res.internal.FeaturesServiceImpl 270 | 23 - org.apache.felix.karaf.features.core - 1.6.0 | Bundles to refresh: 15:58:45,137 | INFO | rint Extender: 2 | SecurityUtils | e.sshd.common.util.SecurityUtils 80 | 30 - sshd-core - 0.4.0 |
Re: Framework release heads-up
This doesn't seem to include the fix to gogo for FELIX-2337, which was committed on 28th May: 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[])] Thanks, Derek On 30 May 2010 23:24, Karl Pauls karlpa...@gmail.com wrote: Just a heads-up on the framework 3.0 release. I have the last outstanding issues fixed now and we published a new snapshot of the distribution which should be the final one (minus the documentation which still needs updating). https://repository.apache.org/content/groups/snapshots-group/org/apache/felix/org.apache.felix.main.distribution/2.1.0-SNAPSHOT/ I plan to call the vote this week so please test it as much as you can :-) regards, Karl -- Karl Pauls karlpa...@gmail.com
[jira] Created: (FELIX-2375) [gogo] when supplied args can't be coerced, the error message prints the arg values, rather than their types
[gogo] when supplied args can't be coerced, the error message prints the arg values, rather than their types Key: FELIX-2375 URL: https://issues.apache.org/jira/browse/FELIX-2375 Project: Felix Issue Type: Bug Components: Gogo Reporter: Derek Baum Priority: Minor e.g. 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[])] This message would be better as: gogo: IllegalArgumentException: Cannot coerce headers(ArrayList) to any of [(Bundle[])] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Framework release heads-up
On 5/31/10 17:34, Derek Baum wrote: This doesn't seem to include the fix to gogo for FELIX-2337, which was committed on 28th May: 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[])] Sorry, that's my fault. I forgot to rebuild Gogo before publishing the distribution snapshot. The final release will included the latest commits for Gogo too. - richard Thanks, Derek On 30 May 2010 23:24, Karl Paulskarlpa...@gmail.com wrote: Just a heads-up on the framework 3.0 release. I have the last outstanding issues fixed now and we published a new snapshot of the distribution which should be the final one (minus the documentation which still needs updating). https://repository.apache.org/content/groups/snapshots-group/org/apache/felix/org.apache.felix.main.distribution/2.1.0-SNAPSHOT/ I plan to call the vote this week so please test it as much as you can :-) regards, Karl -- Karl Pauls karlpa...@gmail.com
Re: Framework release heads-up
On 5/31/10 18:30, Richard S. Hall wrote: On 5/31/10 17:34, Derek Baum wrote: This doesn't seem to include the fix to gogo for FELIX-2337, which was committed on 28th May: 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[])] Sorry, that's my fault. I forgot to rebuild Gogo before publishing the distribution snapshot. The final release will included the latest commits for Gogo too. I just published a new distribution snapshot for safe measures... - richard - richard Thanks, Derek On 30 May 2010 23:24, Karl Paulskarlpa...@gmail.com wrote: Just a heads-up on the framework 3.0 release. I have the last outstanding issues fixed now and we published a new snapshot of the distribution which should be the final one (minus the documentation which still needs updating). https://repository.apache.org/content/groups/snapshots-group/org/apache/felix/org.apache.felix.main.distribution/2.1.0-SNAPSHOT/ I plan to call the vote this week so please test it as much as you can :-) regards, Karl -- Karl Pauls karlpa...@gmail.com
RE: Error with UPnP Base driver
Hi Stefano, Thanks for your reply. I can't actually touch those bundles. Is there another way to do so ? Kind Regards, Charbel. _ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969
Re: [DISCUSS] Move Karaf as a TLP
And here is my +1 for moving karaf to a TLP. Best Regards Freeman On 2010-5-31, at 下午5:14, Gert Vanthienen wrote: L.S., Adding my (late) +1 for moving Karaf to a TLP Not sure if you're still looking for someone to take an initial stab at the project goal or if that's being discussed on the Felix PMC at the moment, but here's my proposal anyway: ... for the creation and maintenance of a small, extensible and enterprise-ready OSGi-based server runtime, capable of being a base framework for building other enterprise server applications, as well as the necessary tools, add-ons and components to facilitate building these applications Regards, Gert Vanthienen On 30 May 2010 22:53, Lukasz Dywicki luk...@dywicki.pl wrote: I would like to say 'yes' for TLP (even if my vote doesn't count). I try contribute Karaf from time to time and I wish continue doing that, when it will move to top level too. For me it does not make sense to try close all OSGi releated things in Felix project. At this moment we have Aries which is also very closer to OSGi but it's not a part of Felix. Best regards, Lukasz Dywicki Jarek Gawor-2 wrote: 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
