Re: [PROPOSAL] Towards Karaf 3.0.0
Hi David, you made a great work and it would be a shame to not use it :) The maven plugin refactoring is a great step forward and we have to use it. We simply have to make a review/test/cleanup in the current trunk assemblies. I raised Jira about that and I will do it. Regards JB On Tue 12/07/11 00:05 , David Jencks wrote:: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and standard assemblies created using kars/features rather than the old style maven-assembly-plugin. I haven't been able to work on this for a while but i thought I left it in a state as least as functional as the old-style servers. The only bit I recall as missing is the legal files. What are you looking for to start e.g. cxf? IIRC you can assemble a server including a cxf feature as a boot feature, or add it in later as a regular feature thanks david jencks
Re: [PROPOSAL] Towards Karaf 3.0.0
Hey David, On Tue, Jul 12, 2011 at 8:12 AM, David Jencks david_jen...@yahoo.com wrote: You can include replacement jre.properties and other properties files in a kar that will overwrite the existing ones. In any case you have to restart the server to pick up the new files. However obviously you can only do this with one kar file before they interfere. Yeah, exactly this is problem :( Has anyone suggested a practical way to deal with this? Maybe provide extension points in the configuration files? Maybe someone else has a more ground-shaking suggestion? :) But my guts say that this will be a VERY valuable feature for Karaf since it may be possible then to start an empty Karaf and simply upgrade it to SMX, or Geronimo or any parts of both you may like to have without ever toughing a text-editor and all those hassels about jre exports and bot delegation :( Thanks and kind regards, Andreas thanks! david jencks Kind regards, Andreas On Tue, Jul 12, 2011 at 12:05 AM, David Jencks david_jen...@yahoo.com wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: big snip * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and standard assemblies created using kars/features rather than the old style maven-assembly-plugin. I haven't been able to work on this for a while but i thought I left it in a state as least as functional as the old-style servers. The only bit I recall as missing is the legal files. What are you looking for to start e.g. cxf? IIRC you can assemble a server including a cxf feature as a boot feature, or add it in later as a regular feature thanks david jencks
Re: [PROPOSAL] Towards Karaf 3.0.0
On Tue, Jul 12, 2011 at 8:23 AM, Charles Moulliard cmoulli...@gmail.com wrote: Hi Andreas, I don't think that we will delay the release of Karaf for 2-3 months if we develop what I suggest. BTW, If we don't do that, our end users will also have to wait maybe a couple of months also to have such features at their disposition. So why are we so hurry to deliver something when the baby is not ready. Apache Karaf lifecycle of releases must be slower compare to Apache Camel, ServiceMix and Geronimo as this is the heart/kernel of other projects. So take the time about the reflection and prepare cleverly this release. Yes and no :) The point here is that there are already valuable features in Karaf (although not that ground shaking; e.g. ways better Kar support) other projects might want to use; I can only speak from my point of view here but it would help me with pax-wicket or the openengsb for example to provide a one-bundle-kar which is also able to overwrite configuration files helping users to pack everything together much easier without such heavy use of the internals of karaf and the other projects :(. But maybe I'm alone with my point of view here? Remarks : - If Karaf Enterprise Repository covers my point, the answer is yes. I don't want to reinvent the wheel but we must provide a repository (outside of Apache world) to be able to deploy features for OpenEJB, Wicket, Vaadin, Hibernate, ... This will facilitate adoption of OSGI world. But don't create a new repo (like OBR or Spring Enterprise Repo) just because we would like that Karaf as it but provide real added values like a certification program, governance rules to develop features files, KAR archive before to deploy them. We've discussed about this already several times (mostly on IRC and on the skype birthday meeting; sry for not making this more present; but there were also 1-2 threads on the ML about this). Basically it's a two way of integration. At first (maybe Karaf 3.0) it is not more than an xml files distributing those features files for wicket, vaadin, In a second step (maybe Karaf 3.1) and with the help of Karaf Cave we can upgrade this to a full OBR supported repository. - If karaf project or karaf subproject does not provide an Enterprise Web Console, who will do that - a commercial company ? This is required by administrators like also scripts to operate / administrate the platform. We must also improve mbean components for JMX management to better operate Karaf and OSGI Services. God beware! Except we may profit from it ;) No, fun aside. I'm only with David here that Karaf (core) might not be the best place for all those features. I think we can either tackle this as a subproject, but tbh I think e.g. Aries would be a much better place for such an enterprise console as they also provide all the enterprise features for Karaf. Kind regards, Andreas Regards, Charles Moulliard Apache Committer Blog : http://cmoulliard.blogspot.com Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard Skype: cmoulliard On Tue, Jul 12, 2011 at 7:26 AM, Andreas Pieber anpie...@gmail.com wrote: Hey Charles, +1, although this will delay Karaf for at least another 2-3 months at least I'm afraid. On Tue, Jul 12, 2011 at 7:05 AM, Charles Moulliard cmoulli...@gmail.com wrote: That means that we must in this release : - Simplify the deployment process of the different archives (EAR, WAR, EBA, JAR, KAR, Spring, Blueprint) and help our end users for doing that through Maven, OBR, ... - Question : Do we have to support all of them ? Maybe we could restrict the deployment of the required type (JAR, Bundle, Spring, Blueprint, WAR ?) and let's project like Geronimo to take care about EAR, EJB modules ? I don't think that Karaf should be responsible for all types. The base types are quite enough. Aries, Geronimo, SMX could provide more specific deployers for different packages (and we almost have those deployers already). I consider it much more important that .kar files could adapt Karaf in an easier way here. - Provide a more Enterprise Web Console for operating Karaf - configuring DataSource(s), web modules, Security, ... Again I'm not sure how far this is the responsibility of Karaf. Although Karaf has the enterprise features file I'm not sure if this is something we really want in the core. We should rather discuss if we shouldn't provide a karaf-enterprise subproject or something similar containing those features (if we want to host this at Karaf at all) (Feel free to create an issue for this point; I'm sure there is none by now). - Add admin profile to restrict usage of the Karaf commands as we only support right now a full admin access Interesting idea. This could definitely add some value (I think we're also lacking an issue for that). - Improve and refactor commands like also the display- e.g. when we display all commands --
Re: [PROPOSAL] Towards Karaf 3.0.0
Hi Bengt, Thanks for your reminder and your feedback about your Karaf usage. I also use Karaf as a pure container (used in Kalumet/AutoDeploy and BuildEraser), so I have the same concerns as yours :) I will plan your Jira on Karaf 3.0.0 as it parts of the profiles/distributions/KAR enhancements. Regards JB On Tue 12/07/11 10:28 , Bengt Rodehav wrote:: Just a little input from a humble user of Karaf... Karaf is not only used by other projects like ServiceMix and Geronimo. It is also used by end users like me. For me, Karaf is a deployment container I use to implement my products. I find it very hard to customize a Karaf server for the purposes of my product. I've created a couple of JIRA's regarding this already (which I think has been postphoned to Karaf 3.1). The way you describe KAR files sounds excellent to me. I could start with a fresh Karaf installation and then install a KAR file which will upgrade Karaf to become a container for my product. It would include all the necessary bundles as well as all the customization of Karaf needed. A dream come true. I realize that when adding configuration settings via a KAR file, there might be conflicts. Don't let this stop you from implementing this feature. A lot of use cases (like mine) would not have more than one KAR containing configuration settings anyway. Let's start by making that work and then (in the next release) make it possible to handle potentially conflicting configuration settings. Please don't target all efforts towards pleasing ServiceMix and Geronimo (although I do of course realize that is very important). Not every user of Karaf is a whole project with resources to customize Karaf (and do it again for every new release of Karaf...). /Bengt 2011/7/12 Andreas Pieber anpie...@gmail.com On Tue, Jul 12, 2011 at 8:33 AM, Charles Moulliard cmoulli...@gmail.com wrote: Hi, If we can with Karaf 3.x proposes a mechanism to upgrade platform from karaf 3.x to 3.y easily, that would be awesome and great. We are OSGI compliant but we don't use it internally to patch/deploy hotfix the platform. +1; I'm completely with your here! This is a pitch. We do not need something very complex but a process which will deploy new jars files for the core and update config files. Then the question will be can we update config files when users modify them Yeah, but to point out the core again: Look at the Apache SMX project for example. There are a lot of modifications to Karaf and the config files to make everything together nicely. Think about out target here: The SMX assembly file should look something like (without the entire mvn syntax by now): karaf-maven-plugin assembe cxf kar (as is from cxf project) amq kar (as is from amq) smx kar (as is from smx) Full stop; nothing else required *DREAMING* :) Kind regards, Andreas Just 2 cents Regards, Charles Moulliard Apache Committer Blog : http://cmoulliard.blogspot.com Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard Skype: cmoulliard On Tue, Jul 12, 2011 at 8:23 AM, Andreas Pieber anpie...@gmail.com wrote: Hey David, On Tue, Jul 12, 2011 at 8:12 AM, David Jencks david_jen...@yahoo.com wrote: You can include replacement jre.properties and other properties files in a kar that will overwrite the existing ones. In any case you have to restart the server to pick up the new files. However obviously you can only do this with one kar file before they interfere. Yeah, exactly this is problem :( Has anyone suggested a practical way to deal with this? Maybe provide extension points in the configuration files? Maybe someone else has a more ground-shaking suggestion? :) But my guts say that this will be a VERY valuable feature for Karaf since it may be possible then to start an empty Karaf and simply upgrade it to SMX, or Geronimo or any parts of both you may like to have without ever toughing a text-editor and all those hassels about jre exports and bot delegation :( Thanks and kind regards, Andreas thanks! david jencks Kind regards, Andreas On Tue, Jul 12, 2011 at 12:05 AM, David Jencks david_jen...@yahoo.com wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and standard assemblies created using kars/features rather than the old style maven-assembly-plugin. I haven't been able to work on this for a while but i thought I left it in a state as least as functional as the old-style servers. The only bit I recall as missing is the legal files. What are you looking for
Re: [PROPOSAL] Towards Karaf 3.0.0
On Tue, Jul 12, 2011 at 1:42 PM, Daniel Kulp dk...@apache.org wrote: On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote: Hey David, The problem isn't during assambling but to install e.g. CXF afterwards. Please start an empty Karaf 3.x and try to install the CXF features file. To make it run you have to modify the jre.properties and the bootdelegation to get it up running. And there is no way to do this automatically from your .kar/features.xml right now :( That should be changing in CXF 2.4.2. The last holdup was a bug in Neethi's OSGi manifest, but a new version of Neethi is under vote now. With that, you should be able to take a clean Karaf and deploy CXF. Thanks for clarifying this! THAT said, IMO, the karaf jre.properties file should exclude the packages that are known not to work in karaf. jaxb-api, stax-api, saaj-api, etc Karaf should then contain a set of API features to install the proper OSGi versions of said API's. Yeah, definitely +1; I really like this idea. We can exclude them by default and add the apis in the enterprise repo. This sounds very good. Would you mind to create an issue for that? Still this does not fixes the problem with the other config files (as described by Bengt) or the problem with the bootdelegation (but here again I think we can add those known to not work well by default?) Kind regards, Andreas Dan Kind regards, Andreas On Tue, Jul 12, 2011 at 12:05 AM, David Jencks david_jen...@yahoo.com wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: big snip * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and standard assemblies created using kars/features rather than the old style maven-assembly-plugin. I haven't been able to work on this for a while but i thought I left it in a state as least as functional as the old-style servers. The only bit I recall as missing is the legal files. What are you looking for to start e.g. cxf? IIRC you can assemble a server including a cxf feature as a boot feature, or add it in later as a regular feature thanks david jencks -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
Awesome Dan, very good news :) Regards JB On Tue 12/07/11 13:42 , Daniel Kulp wrote:: On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote: Hey David, The problem isn't during assambling but to install e.g. CXF afterwards. Please start an empty Karaf 3.x and try to install the CXF features file. To make it run you have to modify the jre.properties and the bootdelegation to get it up running. And there is no way to do this automatically from your .kar/features.xml right now :( That should be changing in CXF 2.4.2.The last holdup was a bug in Neethi's OSGi manifest, but a new version of Neethi is under vote now. With that, you should be able to take a clean Karaf and deploy CXF. THAT said, IMO, the karaf jre.properties file should exclude the packages that are known not to work in karaf. jaxb-api, stax-api, saaj-api, etc Karaf should then contain a set of API features to install the proper OSGi versions of said API's. Dan Kind regards, Andreas On Tue, Jul 12, 2011 at 12:05 AM, David Jencks david_jen...@yahoo.com wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and standard assemblies created using kars/features rather than the old style maven-assembly-plugin. I haven't been able to work on this for a while but i thought I left it in a state as least as functional as the old-style servers. The only bit I recall as missing is the legal files. What are you looking for to start e.g. cxf? IIRC you can assemble a server including a cxf feature as a boot feature, or add it in later as a regular feature thanks david jencks -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
I disagree with that. Jaxb, stax and other libraries provided by the JRE work in OSGi afaik with the JRE implementation. People have complained in the past that the default karaf behavior did not allow them to leverage those technologies provided by the JRE, that's why we changed the exported packages to reflect what the JRE provides. For all the OSGi users that don't use CXF and don't require a specific stax implementation or something like that, I'd like to keep the current behavior. Note that when you get to the borders of the OSGi specs, everything is not clearly defined. Another problem is caused by the fact that the packages provided by the JRE are not versioned. I think the current behavior is the best one for a generic container, but I agree we have to tweak it for CXF or ServiceMix, so be it, I think that's the responsibility of those projects to do it, though Karaf could provided a good way to allow those modifications. On Tue, Jul 12, 2011 at 13:42, Daniel Kulp dk...@apache.org wrote: On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote: Hey David, The problem isn't during assambling but to install e.g. CXF afterwards. Please start an empty Karaf 3.x and try to install the CXF features file. To make it run you have to modify the jre.properties and the bootdelegation to get it up running. And there is no way to do this automatically from your .kar/features.xml right now :( That should be changing in CXF 2.4.2.The last holdup was a bug in Neethi's OSGi manifest, but a new version of Neethi is under vote now. With that, you should be able to take a clean Karaf and deploy CXF. THAT said, IMO, the karaf jre.properties file should exclude the packages that are known not to work in karaf. jaxb-api, stax-api, saaj-api, etc Karaf should then contain a set of API features to install the proper OSGi versions of said API's. Dan Kind regards, Andreas On Tue, Jul 12, 2011 at 12:05 AM, David Jencks david_jen...@yahoo.com wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: big snip * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and standard assemblies created using kars/features rather than the old style maven-assembly-plugin. I haven't been able to work on this for a while but i thought I left it in a state as least as functional as the old-style servers. The only bit I recall as missing is the legal files. What are you looking for to start e.g. cxf? IIRC you can assemble a server including a cxf feature as a boot feature, or add it in later as a regular feature thanks david jencks -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [PROPOSAL] Towards Karaf 3.0.0
So it really seems like we need a way to incrementally modify at least jre.properties and possibly the boot delegation property. It isn't possible to use a fragment bundle with the framework as host to change the (effective) jre.properties, is it? If that won't work maybe we can merge property files something like jre-BSN.properties merges with jre.properties. An entry like jdk6=javax.foo,\ !javax.bar,\ !javax.baz has the result of adding the javax.foo to the jdk6 exports and removing javax.bar and javax.baz. I think I saw someone claim recently that for the bootdelegation property the framework already understands entries like !com.sun.xml.bind so maybe for that property we can just merge everything together into one string. thanks david jencks On Jul 12, 2011, at 9:09 AM, Guillaume Nodet wrote: I disagree with that. Jaxb, stax and other libraries provided by the JRE work in OSGi afaik with the JRE implementation. People have complained in the past that the default karaf behavior did not allow them to leverage those technologies provided by the JRE, that's why we changed the exported packages to reflect what the JRE provides. For all the OSGi users that don't use CXF and don't require a specific stax implementation or something like that, I'd like to keep the current behavior. Note that when you get to the borders of the OSGi specs, everything is not clearly defined. Another problem is caused by the fact that the packages provided by the JRE are not versioned. I think the current behavior is the best one for a generic container, but I agree we have to tweak it for CXF or ServiceMix, so be it, I think that's the responsibility of those projects to do it, though Karaf could provided a good way to allow those modifications. On Tue, Jul 12, 2011 at 13:42, Daniel Kulp dk...@apache.org wrote: On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote: Hey David, The problem isn't during assambling but to install e.g. CXF afterwards. Please start an empty Karaf 3.x and try to install the CXF features file. To make it run you have to modify the jre.properties and the bootdelegation to get it up running. And there is no way to do this automatically from your .kar/features.xml right now :( That should be changing in CXF 2.4.2.The last holdup was a bug in Neethi's OSGi manifest, but a new version of Neethi is under vote now. With that, you should be able to take a clean Karaf and deploy CXF. THAT said, IMO, the karaf jre.properties file should exclude the packages that are known not to work in karaf. jaxb-api, stax-api, saaj-api, etc Karaf should then contain a set of API features to install the proper OSGi versions of said API's. Dan Kind regards, Andreas On Tue, Jul 12, 2011 at 12:05 AM, David Jencks david_jen...@yahoo.com wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: big snip * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and standard assemblies created using kars/features rather than the old style maven-assembly-plugin. I haven't been able to work on this for a while but i thought I left it in a state as least as functional as the old-style servers. The only bit I recall as missing is the legal files. What are you looking for to start e.g. cxf? IIRC you can assemble a server including a cxf feature as a boot feature, or add it in later as a regular feature thanks david jencks -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [PROPOSAL] Towards Karaf 3.0.0
Thanks JB - I just wanted to make sure that all use cases (especially mine of course) are covered. Looking forward to 3.0! /Bengt 2011/7/12 Jean-Baptiste Onofré j...@nanthrax.net Hi Bengt, Thanks for your reminder and your feedback about your Karaf usage. I also use Karaf as a pure container (used in Kalumet/AutoDeploy and BuildEraser), so I have the same concerns as yours :) I will plan your Jira on Karaf 3.0.0 as it parts of the profiles/distributions/KAR enhancements. Regards JB On Tue 12/07/11 10:28 , Bengt Rodehav wrote:: Just a little input from a humble user of Karaf... Karaf is not only used by other projects like ServiceMix and Geronimo. It is also used by end users like me. For me, Karaf is a deployment container I use to implement my products. I find it very hard to customize a Karaf server for the purposes of my product. I've created a couple of JIRA's regarding this already (which I think has been postphoned to Karaf 3.1). The way you describe KAR files sounds excellent to me. I could start with a fresh Karaf installation and then install a KAR file which will upgrade Karaf to become a container for my product. It would include all the necessary bundles as well as all the customization of Karaf needed. A dream come true. I realize that when adding configuration settings via a KAR file, there might be conflicts. Don't let this stop you from implementing this feature. A lot of use cases (like mine) would not have more than one KAR containing configuration settings anyway. Let's start by making that work and then (in the next release) make it possible to handle potentially conflicting configuration settings. Please don't target all efforts towards pleasing ServiceMix and Geronimo (although I do of course realize that is very important). Not every user of Karaf is a whole project with resources to customize Karaf (and do it again for every new release of Karaf...). /Bengt 2011/7/12 Andreas Pieber anpie...@gmail.com On Tue, Jul 12, 2011 at 8:33 AM, Charles Moulliard cmoulli...@gmail.com wrote: Hi, If we can with Karaf 3.x proposes a mechanism to upgrade platform from karaf 3.x to 3.y easily, that would be awesome and great. We are OSGI compliant but we don't use it internally to patch/deploy hotfix the platform. +1; I'm completely with your here! This is a pitch. We do not need something very complex but a process which will deploy new jars files for the core and update config files. Then the question will be can we update config files when users modify them Yeah, but to point out the core again: Look at the Apache SMX project for example. There are a lot of modifications to Karaf and the config files to make everything together nicely. Think about out target here: The SMX assembly file should look something like (without the entire mvn syntax by now): karaf-maven-plugin assembe cxf kar (as is from cxf project) amq kar (as is from amq) smx kar (as is from smx) Full stop; nothing else required *DREAMING* :) Kind regards, Andreas Just 2 cents Regards, Charles Moulliard Apache Committer Blog : http://cmoulliard.blogspot.com Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard Skype: cmoulliard On Tue, Jul 12, 2011 at 8:23 AM, Andreas Pieber anpie...@gmail.com wrote: Hey David, On Tue, Jul 12, 2011 at 8:12 AM, David Jencks david_jen...@yahoo.com wrote: You can include replacement jre.properties and other properties files in a kar that will overwrite the existing ones. In any case you have to restart the server to pick up the new files. However obviously you can only do this with one kar file before they interfere. Yeah, exactly this is problem :( Has anyone suggested a practical way to deal with this? Maybe provide extension points in the configuration files? Maybe someone else has a more ground-shaking suggestion? :) But my guts say that this will be a VERY valuable feature for Karaf since it may be possible then to start an empty Karaf and simply upgrade it to SMX, or Geronimo or any parts of both you may like to have without ever toughing a text-editor and all those hassels about jre exports and bot delegation :( Thanks and kind regards, Andreas thanks! david jencks Kind regards, Andreas On Tue, Jul 12, 2011 at 12:05 AM, David Jencks david_jen...@yahoo.com wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and
Re: [PROPOSAL] Towards Karaf 3.0.0
David, From my experience, the only time I need to use a negation operator in jre.properties is if I want to explictly show users (folks reading the jre.properties file) that my implementation of Karaf does not use that package. If I don't want a package from the jre to be used in my instance of Karaf, I simply exclude that package from the list of packages exported into karaf. Feel free to correct me if I'm wrong. :-) David Jencks wrote: So it really seems like we need a way to incrementally modify at least jre.properties and possibly the boot delegation property. It isn't possible to use a fragment bundle with the framework as host to change the (effective) jre.properties, is it? If that won't work maybe we can merge property files something like jre-BSN.properties merges with jre.properties. An entry like jdk6=javax.foo,\ !javax.bar,\ !javax.baz has the result of adding the javax.foo to the jdk6 exports and removing javax.bar and javax.baz. I think I saw someone claim recently that for the bootdelegation property the framework already understands entries like !com.sun.xml.bind so maybe for that property we can just merge everything together into one string. thanks david jencks On Jul 12, 2011, at 9:09 AM, Guillaume Nodet wrote: I disagree with that. Jaxb, stax and other libraries provided by the JRE work in OSGi afaik with the JRE implementation. People have complained in the past that the default karaf behavior did not allow them to leverage those technologies provided by the JRE, that's why we changed the exported packages to reflect what the JRE provides. For all the OSGi users that don't use CXF and don't require a specific stax implementation or something like that, I'd like to keep the current behavior. Note that when you get to the borders of the OSGi specs, everything is not clearly defined. Another problem is caused by the fact that the packages provided by the JRE are not versioned. I think the current behavior is the best one for a generic container, but I agree we have to tweak it for CXF or ServiceMix, so be it, I think that's the responsibility of those projects to do it, though Karaf could provided a good way to allow those modifications. On Tue, Jul 12, 2011 at 13:42, Daniel Kulp lt;dk...@apache.orggt; wrote: On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote: Hey David, The problem isn't during assambling but to install e.g. CXF afterwards. Please start an empty Karaf 3.x and try to install the CXF features file. To make it run you have to modify the jre.properties and the bootdelegation to get it up running. And there is no way to do this automatically from your .kar/features.xml right now :( That should be changing in CXF 2.4.2.The last holdup was a bug in Neethi's OSGi manifest, but a new version of Neethi is under vote now. With that, you should be able to take a clean Karaf and deploy CXF. THAT said, IMO, the karaf jre.properties file should exclude the packages that are known not to work in karaf. jaxb-api, stax-api, saaj-api, etc Karaf should then contain a set of API features to install the proper OSGi versions of said API's. Dan Kind regards, Andreas On Tue, Jul 12, 2011 at 12:05 AM, David Jencks lt;david_jen...@yahoo.comgt; wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: big snip * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and standard assemblies created using kars/features rather than the old style maven-assembly-plugin. I haven't been able to work on this for a while but i thought I left it in a state as least as functional as the old-style servers. The only bit I recall as missing is the legal files. What are you looking for to start e.g. cxf? IIRC you can assemble a server including a cxf feature as a boot feature, or add it in later as a regular feature thanks david jencks -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com -- Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com - Mike Van -- View this message in context: http://karaf.922171.n3.nabble.com/PROPOSAL-Towards-Karaf-3-0-0-tp3158763p3163632.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [PROPOSAL] Towards Karaf 3.0.0
I probably didn't explain my idea very well I was thinking that the base jre.properties might have javax.xml.bind in the jdk6 entry in it to indicate that it's using the jaxb 2.1 api and implementation shipped with java 6. If you needed say osgi-friendly jaxb 2.2 api and the separate snoracle implementation you could have a kar indicating the geronimo jaxb 2.2 spec and (smx?) bundlized snoracle 2.2 jaxb impl together with a patch properties with !javax.xml.bind which would have the effect of removing the entry from the jdk6 entry. So the purpose here is to provide a way to modify the effective jre.properties by installing a .kar file rather than editing it by hand. thanks david jencks On Jul 12, 2011, at 12:33 PM, mikevan wrote: David, From my experience, the only time I need to use a negation operator in jre.properties is if I want to explictly show users (folks reading the jre.properties file) that my implementation of Karaf does not use that package. If I don't want a package from the jre to be used in my instance of Karaf, I simply exclude that package from the list of packages exported into karaf. Feel free to correct me if I'm wrong. :-) David Jencks wrote: So it really seems like we need a way to incrementally modify at least jre.properties and possibly the boot delegation property. It isn't possible to use a fragment bundle with the framework as host to change the (effective) jre.properties, is it? If that won't work maybe we can merge property files something like jre-BSN.properties merges with jre.properties. An entry like jdk6=javax.foo,\ !javax.bar,\ !javax.baz has the result of adding the javax.foo to the jdk6 exports and removing javax.bar and javax.baz. I think I saw someone claim recently that for the bootdelegation property the framework already understands entries like !com.sun.xml.bind so maybe for that property we can just merge everything together into one string. thanks david jencks On Jul 12, 2011, at 9:09 AM, Guillaume Nodet wrote: I disagree with that. Jaxb, stax and other libraries provided by the JRE work in OSGi afaik with the JRE implementation. People have complained in the past that the default karaf behavior did not allow them to leverage those technologies provided by the JRE, that's why we changed the exported packages to reflect what the JRE provides. For all the OSGi users that don't use CXF and don't require a specific stax implementation or something like that, I'd like to keep the current behavior. Note that when you get to the borders of the OSGi specs, everything is not clearly defined. Another problem is caused by the fact that the packages provided by the JRE are not versioned. I think the current behavior is the best one for a generic container, but I agree we have to tweak it for CXF or ServiceMix, so be it, I think that's the responsibility of those projects to do it, though Karaf could provided a good way to allow those modifications. On Tue, Jul 12, 2011 at 13:42, Daniel Kulp lt;dk...@apache.orggt; wrote: On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote: Hey David, The problem isn't during assambling but to install e.g. CXF afterwards. Please start an empty Karaf 3.x and try to install the CXF features file. To make it run you have to modify the jre.properties and the bootdelegation to get it up running. And there is no way to do this automatically from your .kar/features.xml right now :( That should be changing in CXF 2.4.2.The last holdup was a bug in Neethi's OSGi manifest, but a new version of Neethi is under vote now. With that, you should be able to take a clean Karaf and deploy CXF. THAT said, IMO, the karaf jre.properties file should exclude the packages that are known not to work in karaf. jaxb-api, stax-api, saaj-api, etc Karaf should then contain a set of API features to install the proper OSGi versions of said API's. Dan Kind regards, Andreas On Tue, Jul 12, 2011 at 12:05 AM, David Jencks lt;david_jen...@yahoo.comgt; wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: big snip * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and standard assemblies created using kars/features rather than the old style maven-assembly-plugin. I haven't been able to work on this for a while but i thought I left it in a state as least as functional as the old-style servers. The only bit I recall as missing is the legal files. What are you looking for to start e.g. cxf? IIRC you can assemble a server including a cxf feature as a boot feature, or add it in later as a regular feature
Re: [PROPOSAL] Towards Karaf 3.0.0
Hm, I'm not sure. For example you set the javax.xml.bind to version 2.1.3 because that is the one used since update 4 you're still able to deploy the 2.1.13 next to it and define your dependencies to version [2.1.13, 2.2). This way you are sure you use the one you need. If you leave the jre to 0.0.0.0 it's the one used even though you required it to be 2.1.13. regards, Achim Am 12.07.2011 23:23, schrieb Daniel Kulp: On Tuesday, July 12, 2011 10:59:09 PM Achim Nierbeck wrote: I think the jaxb stuff is a very specific problem we have and I ran into that one quite a lot :-) my best practice has been to version the crucial part of the jre.properties. For example I did a versioning for jaxb like the following in the jre.properties: javax.xml.bind;version=2.1, \ This way I was able to make sure that jaxb isn't provided as 0.0.0.0 which is usually picked up during resolving. Like Neil Bartlett mentions in his blog http://njbartlett.name/2011/02/09/uses-constraints.html I would suggest since the jre.properties are already split up between 1.5 and 1.6 java version to add those versions to the crucial parts of the jre.properties. But that doesn't actually work. If you NEED to get a JAXB 2.1.13 installed into the JRE due to the fact that the version in anything other than the latest JRE is buggy (leaks memory and locks classloaders, for example), just doing that won't work.You need to actual API jar that has the osgi extensions in it. Dan Regards, Achim Am 12.07.2011 21:41, schrieb David Jencks: I probably didn't explain my idea very well I was thinking that the base jre.properties might have javax.xml.bind in the jdk6 entry in it to indicate that it's using the jaxb 2.1 api and implementation shipped with java 6. If you needed say osgi-friendly jaxb 2.2 api and the separate snoracle implementation you could have a kar indicating the geronimo jaxb 2.2 spec and (smx?) bundlized snoracle 2.2 jaxb impl together with a patch properties with !javax.xml.bind which would have the effect of removing the entry from the jdk6 entry. So the purpose here is to provide a way to modify the effective jre.properties by installing a .kar file rather than editing it by hand. thanks david jencks On Jul 12, 2011, at 12:33 PM, mikevan wrote: David, From my experience, the only time I need to use a negation operator in jre.properties is if I want to explictly show users (folks reading the jre.properties file) that my implementation of Karaf does not use that package. If I don't want a package from the jre to be used in my instance of Karaf, I simply exclude that package from the list of packages exported into karaf. Feel free to correct me if I'm wrong. :-) David Jencks wrote: So it really seems like we need a way to incrementally modify at least jre.properties and possibly the boot delegation property. It isn't possible to use a fragment bundle with the framework as host to change the (effective) jre.properties, is it? If that won't work maybe we can merge property files something like jre-BSN.properties merges with jre.properties. An entry like jdk6=javax.foo,\ !javax.bar,\ !javax.baz has the result of adding the javax.foo to the jdk6 exports and removing javax.bar and javax.baz. I think I saw someone claim recently that for the bootdelegation property the framework already understands entries like !com.sun.xml.bind so maybe for that property we can just merge everything together into one string. thanks david jencks On Jul 12, 2011, at 9:09 AM, Guillaume Nodet wrote: I disagree with that. Jaxb, stax and other libraries provided by the JRE work in OSGi afaik with the JRE implementation. People have complained in the past that the default karaf behavior did not allow them to leverage those technologies provided by the JRE, that's why we changed the exported packages to reflect what the JRE provides. For all the OSGi users that don't use CXF and don't require a specific stax implementation or something like that, I'd like to keep the current behavior. Note that when you get to the borders of the OSGi specs, everything is not clearly defined. Another problem is caused by the fact that the packages provided by the JRE are not versioned. I think the current behavior is the best one for a generic container, but I agree we have to tweak it for CXF or ServiceMix, so be it, I think that's the responsibility of those projects to do it, though Karaf could provided a good way to allow those modifications. On Tue, Jul 12, 2011 at 13:42, Daniel Kulp lt;dk...@apache.orggt; wrote: On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote: Hey David, The problem isn't during assambling but to install e.g. CXF afterwards. Please start an empty Karaf 3.x and try to install the CXF features file. To make it run you have to modify the jre.properties and the bootdelegation to get it up running. And
Re: [PROPOSAL] Towards Karaf 3.0.0
On Jul 12, 2011, at 2:28 PM, Daniel Kulp wrote: On Tuesday, July 12, 2011 12:41:18 PM David Jencks wrote: I probably didn't explain my idea very well I was thinking that the base jre.properties might have javax.xml.bind in the jdk6 entry in it to indicate that it's using the jaxb 2.1 api and implementation shipped with java 6. If you needed say osgi-friendly jaxb 2.2 api and the separate snoracle implementation you could have a kar indicating the geronimo jaxb 2.2 spec and (smx?) bundlized snoracle 2.2 jaxb impl together with a patch properties with !javax.xml.bind which would have the effect of removing the entry from the jdk6 entry. So the purpose here is to provide a way to modify the effective jre.properties by installing a .kar file rather than editing it by hand. The question I have is how possible is it to do that without restarting Karaf, or would restarting Karaf after installing the jaxb kar be required? Would there be an impact on existing things running using jaxb? I don't see how its plausible to make changes in what the framework exports without restarting karaf. Can you refresh the framework? Is this different from restarting? I actually hope or expect we'll make it so easy to assembly your own custom server with maven that the normal use case will be that rather than installing stuff into a running instance of someone else's idea of what karaf should be. david jencks Dan thanks david jencks On Jul 12, 2011, at 12:33 PM, mikevan wrote: David, From my experience, the only time I need to use a negation operator in jre.properties is if I want to explictly show users (folks reading the jre.properties file) that my implementation of Karaf does not use that package. If I don't want a package from the jre to be used in my instance of Karaf, I simply exclude that package from the list of packages exported into karaf. Feel free to correct me if I'm wrong. :-) David Jencks wrote: So it really seems like we need a way to incrementally modify at least jre.properties and possibly the boot delegation property. It isn't possible to use a fragment bundle with the framework as host to change the (effective) jre.properties, is it? If that won't work maybe we can merge property files something like jre-BSN.properties merges with jre.properties. An entry like jdk6=javax.foo,\ !javax.bar,\ !javax.baz has the result of adding the javax.foo to the jdk6 exports and removing javax.bar and javax.baz. I think I saw someone claim recently that for the bootdelegation property the framework already understands entries like !com.sun.xml.bind so maybe for that property we can just merge everything together into one string. thanks david jencks On Jul 12, 2011, at 9:09 AM, Guillaume Nodet wrote: I disagree with that. Jaxb, stax and other libraries provided by the JRE work in OSGi afaik with the JRE implementation. People have complained in the past that the default karaf behavior did not allow them to leverage those technologies provided by the JRE, that's why we changed the exported packages to reflect what the JRE provides. For all the OSGi users that don't use CXF and don't require a specific stax implementation or something like that, I'd like to keep the current behavior. Note that when you get to the borders of the OSGi specs, everything is not clearly defined. Another problem is caused by the fact that the packages provided by the JRE are not versioned. I think the current behavior is the best one for a generic container, but I agree we have to tweak it for CXF or ServiceMix, so be it, I think that's the responsibility of those projects to do it, though Karaf could provided a good way to allow those modifications. On Tue, Jul 12, 2011 at 13:42, Daniel Kulp lt;dk...@apache.orggt; wrote: On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote: Hey David, The problem isn't during assambling but to install e.g. CXF afterwards. Please start an empty Karaf 3.x and try to install the CXF features file. To make it run you have to modify the jre.properties and the bootdelegation to get it up running. And there is no way to do this automatically from your .kar/features.xml right now :( That should be changing in CXF 2.4.2.The last holdup was a bug in Neethi's OSGi manifest, but a new version of Neethi is under vote now. With that, you should be able to take a clean Karaf and deploy CXF. THAT said, IMO, the karaf jre.properties file should exclude the packages that are known not to work in karaf. jaxb-api, stax-api, saaj-api, etc Karaf should then contain a set of API features to install the proper OSGi versions of said API's. Dan Kind regards, Andreas On Tue, Jul 12, 2011 at 12:05 AM, David Jencks lt;david_jen...@yahoo.comgt; wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: big snip * Karaf
Re: [PROPOSAL] Towards Karaf 3.0.0
Another way just comes to my mind. Instead of using the jre.properties we might just add a fragment bundle containing only a manifest like the following: Export-Package: ... javax.xml.bind;version=2.1.3,\ Fragment-Host: system.bundle; extension:=framework since it's a framework extension it will add it's exports to the system bundle. This way we get rid of the jre.properties and are able to change the way the system.bundle exports certain packages. So if someone is in need of a specialized fragment he just might add that one instead of the one provided out-of-the-box. wdyt? I think glassfish adds certain jre packages to the system.bundle regards, Achim Am 12.07.2011 23:46, schrieb David Jencks: On Jul 12, 2011, at 2:28 PM, Daniel Kulp wrote: On Tuesday, July 12, 2011 12:41:18 PM David Jencks wrote: I probably didn't explain my idea very well I was thinking that the base jre.properties might have javax.xml.bind in the jdk6 entry in it to indicate that it's using the jaxb 2.1 api and implementation shipped with java 6. If you needed say osgi-friendly jaxb 2.2 api and the separate snoracle implementation you could have a kar indicating the geronimo jaxb 2.2 spec and (smx?) bundlized snoracle 2.2 jaxb impl together with a patch properties with !javax.xml.bind which would have the effect of removing the entry from the jdk6 entry. So the purpose here is to provide a way to modify the effective jre.properties by installing a .kar file rather than editing it by hand. The question I have is how possible is it to do that without restarting Karaf, or would restarting Karaf after installing the jaxb kar be required? Would there be an impact on existing things running using jaxb? I don't see how its plausible to make changes in what the framework exports without restarting karaf. Can you refresh the framework? Is this different from restarting? I actually hope or expect we'll make it so easy to assembly your own custom server with maven that the normal use case will be that rather than installing stuff into a running instance of someone else's idea of what karaf should be. david jencks Dan thanks david jencks On Jul 12, 2011, at 12:33 PM, mikevan wrote: David, From my experience, the only time I need to use a negation operator in jre.properties is if I want to explictly show users (folks reading the jre.properties file) that my implementation of Karaf does not use that package. If I don't want a package from the jre to be used in my instance of Karaf, I simply exclude that package from the list of packages exported into karaf. Feel free to correct me if I'm wrong. :-) David Jencks wrote: So it really seems like we need a way to incrementally modify at least jre.properties and possibly the boot delegation property. It isn't possible to use a fragment bundle with the framework as host to change the (effective) jre.properties, is it? If that won't work maybe we can merge property files something like jre-BSN.properties merges with jre.properties. An entry like jdk6=javax.foo,\ !javax.bar,\ !javax.baz has the result of adding the javax.foo to the jdk6 exports and removing javax.bar and javax.baz. I think I saw someone claim recently that for the bootdelegation property the framework already understands entries like !com.sun.xml.bind so maybe for that property we can just merge everything together into one string. thanks david jencks On Jul 12, 2011, at 9:09 AM, Guillaume Nodet wrote: I disagree with that. Jaxb, stax and other libraries provided by the JRE work in OSGi afaik with the JRE implementation. People have complained in the past that the default karaf behavior did not allow them to leverage those technologies provided by the JRE, that's why we changed the exported packages to reflect what the JRE provides. For all the OSGi users that don't use CXF and don't require a specific stax implementation or something like that, I'd like to keep the current behavior. Note that when you get to the borders of the OSGi specs, everything is not clearly defined. Another problem is caused by the fact that the packages provided by the JRE are not versioned. I think the current behavior is the best one for a generic container, but I agree we have to tweak it for CXF or ServiceMix, so be it, I think that's the responsibility of those projects to do it, though Karaf could provided a good way to allow those modifications. On Tue, Jul 12, 2011 at 13:42, Daniel Kulp lt;dk...@apache.orggt; wrote: On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote: Hey David, The problem isn't during assambling but to install e.g. CXF afterwards. Please start an empty Karaf 3.x and try to install the CXF features file. To make it run you have to modify the jre.properties and the bootdelegation to get it up running. And there is no way to do this automatically from your
Re: [PROPOSAL] Towards Karaf 3.0.0
I kinda like that On Jul 12, 2011, at 4:14 PM, Achim Nierbeck wrote: Another way just comes to my mind. Instead of using the jre.properties we might just add a fragment bundle containing only a manifest like the following: Export-Package: ... javax.xml.bind;version=2.1.3,\ Fragment-Host: system.bundle; extension:=framework since it's a framework extension it will add it's exports to the system bundle. This way we get rid of the jre.properties and are able to change the way the system.bundle exports certain packages. So if someone is in need of a specialized fragment he just might add that one instead of the one provided out-of-the-box. wdyt? I think glassfish adds certain jre packages to the system.bundle regards, Achim Am 12.07.2011 23:46, schrieb David Jencks: On Jul 12, 2011, at 2:28 PM, Daniel Kulp wrote: On Tuesday, July 12, 2011 12:41:18 PM David Jencks wrote: I probably didn't explain my idea very well I was thinking that the base jre.properties might have javax.xml.bind in the jdk6 entry in it to indicate that it's using the jaxb 2.1 api and implementation shipped with java 6. If you needed say osgi-friendly jaxb 2.2 api and the separate snoracle implementation you could have a kar indicating the geronimo jaxb 2.2 spec and (smx?) bundlized snoracle 2.2 jaxb impl together with a patch properties with !javax.xml.bind which would have the effect of removing the entry from the jdk6 entry. So the purpose here is to provide a way to modify the effective jre.properties by installing a .kar file rather than editing it by hand. The question I have is how possible is it to do that without restarting Karaf, or would restarting Karaf after installing the jaxb kar be required? Would there be an impact on existing things running using jaxb? I don't see how its plausible to make changes in what the framework exports without restarting karaf. Can you refresh the framework? Is this different from restarting? I actually hope or expect we'll make it so easy to assembly your own custom server with maven that the normal use case will be that rather than installing stuff into a running instance of someone else's idea of what karaf should be. david jencks Dan thanks david jencks On Jul 12, 2011, at 12:33 PM, mikevan wrote: David, From my experience, the only time I need to use a negation operator in jre.properties is if I want to explictly show users (folks reading the jre.properties file) that my implementation of Karaf does not use that package. If I don't want a package from the jre to be used in my instance of Karaf, I simply exclude that package from the list of packages exported into karaf. Feel free to correct me if I'm wrong. :-) David Jencks wrote: So it really seems like we need a way to incrementally modify at least jre.properties and possibly the boot delegation property. It isn't possible to use a fragment bundle with the framework as host to change the (effective) jre.properties, is it? If that won't work maybe we can merge property files something like jre-BSN.properties merges with jre.properties. An entry like jdk6=javax.foo,\ !javax.bar,\ !javax.baz has the result of adding the javax.foo to the jdk6 exports and removing javax.bar and javax.baz. I think I saw someone claim recently that for the bootdelegation property the framework already understands entries like !com.sun.xml.bind so maybe for that property we can just merge everything together into one string. thanks david jencks On Jul 12, 2011, at 9:09 AM, Guillaume Nodet wrote: I disagree with that. Jaxb, stax and other libraries provided by the JRE work in OSGi afaik with the JRE implementation. People have complained in the past that the default karaf behavior did not allow them to leverage those technologies provided by the JRE, that's why we changed the exported packages to reflect what the JRE provides. For all the OSGi users that don't use CXF and don't require a specific stax implementation or something like that, I'd like to keep the current behavior. Note that when you get to the borders of the OSGi specs, everything is not clearly defined. Another problem is caused by the fact that the packages provided by the JRE are not versioned. I think the current behavior is the best one for a generic container, but I agree we have to tweak it for CXF or ServiceMix, so be it, I think that's the responsibility of those projects to do it, though Karaf could provided a good way to allow those modifications. On Tue, Jul 12, 2011 at 13:42, Daniel Kulp lt;dk...@apache.orggt; wrote: On Tuesday, July 12, 2011 7:28:57 AM Andreas Pieber wrote: Hey David, The problem isn't during assambling but to install e.g. CXF afterwards. Please start an empty Karaf 3.x and try to install the CXF features file. To make it run you have to modify the
Re: [PROPOSAL] Towards Karaf 3.0.0
if you are talking about spifly I'd rather avoid that since it perverts the semantics of ServiceLoader. In Geronimo we have something that while untested and needing to be added to the boot class path reimplements ServiceLoader to work with the ProviderRegistry and make ServiceLoader work with osgi. This does only work with apis that actually use ServiceLoader rather than the ones that just sort of act like they do thanks david jencks On Jul 12, 2011, at 3:38 PM, Daniel Kulp wrote: The issue is less the impl version than it is the api version. The API version is just 2.1, not 2.1.13. What happens if the system is exported as 2.1 and we then add a real osgi engabled version that is also 2.1? The API's are exactly the same, is just the FactoryFinder class that is really different. We DEFINITELY need to make sure we get the osgi version of the 2.1 so it would find the 2.1.13 impl bundle. Kind of wondering if davidb's stuff in Aries would come into play better here... Dan On Tuesday, July 12, 2011 11:55:30 PM Christian Schneider wrote: I don`t really understand why it should not work to export the system package as the version it really is. So if the jdk 1.6 exports 2.1.0 for example we should export it as that. Then a bundle could still require the version 2.1.13 and it should then take a separate version from outside the jdk. Christian Am 12.07.2011 23:23, schrieb Daniel Kulp: javax.xml.bind;version=2.1, \ This way I was able to make sure that jaxb isn't provided as 0.0.0.0 which is usually picked up during resolving. Like Neil Bartlett mentions in his blog http://njbartlett.name/2011/02/09/uses-constraints.html I would suggest since the jre.properties are already split up between 1.5 and 1.6 java version to add those versions to the crucial parts of the jre.properties. But that doesn't actually work. If you NEED to get a JAXB 2.1.13 installed into the JRE due to the fact that the version in anything other than the latest JRE is buggy (leaks memory and locks classloaders, for example), just doing that won't work.You need to actual API jar that has the osgi extensions in it. Dan -- Daniel Kulp dk...@apache.org http://dankulp.com/blog Talend - http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
Hi JB, thanx for cleaning up Jira and filling up my mailbox ;-) +1 on the road map +1 on the new Jira Components +1 on SVN +1 on quality, I really think we need to make sure this one runs out of the box as 3.0.0 without sending a 3.0.1 shortly afterwards. do we have sonar for Karaf yet? If so we should link that from the karaf homepage regards, Achim 2011/7/11 Jean-Baptiste Onofré j...@nanthrax.net: Hi all, We should now focus on the Karaf 3.0.0 release. I have a set of proposals to deal with you. 1 - Jira -- As you certainly saw in your mailbox, I started to prepare the Karaf 3.0.0 roadmap. I edited Jira issues to add a fix version and the component. Feel free to review directly the issues associated to the 3.0.0 release (simply search the fix version 3.0.0 in Jira). We have also: - Karaf 3.0.1 - Karaf 3.1.0 where you can move the issues depending of the severity/priority. I would like also to propose some changes in the Jira components. Currently, the Jira components are not very helpful. I think that we need more fine-grained components. I propose: - OBR: all issues related to OBR - Shell: all issues related to shell display and shell commands (it's currently console) - WebConsole: all issues related to the web console - WebContainer: all issues related to the web container, web deployer, Pax-Web - Features: all issues related to Karaf features - WrapDeployer: all issues related to wrap deployer - KAR: all issues related to KAR artifact and deployer - OSGi/Runtime: all issues related to bundle installation, OSGi framework, etc - Cellar: all issues related to Karaf Cellar 2 - Subversion Currently Karaf 3.0.0 is the Karaf trunk. I propose: - to focus on the Jira issues first, that it should be fixed on trunk - release Karaf 3.0.0 - when Karaf 3.0.0 is out, I will create the karaf-3.0.x branch, and the trunk will become Karaf 3.1.0 Is it OK for you ? 3 - Quality -- Karaf 3.0.0 is an important release. It's expected by a lot of people and projects, and for a long time now :) It's really important that we insure the highest quality for this release. It means that I don't wanna rush on this release: I would like that we take a time to make clean code, deep tests, add the unit tests when it's required, etc. So, no rush, we take the time that we need :) Thanks Regards JB -- -- *Achim Nierbeck* Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead
Re: [PROPOSAL] Towards Karaf 3.0.0
Good reminder for Sonar. We discussed about that in the past, but we didn't enable it. Let me raise a Jira for that. Thanks Regards JB On Mon 11/07/11 12:35 , Achim Nierbeck wrote:: Hi JB, thanx for cleaning up Jira and filling up my mailbox ;-) +1 on the road map +1 on the new Jira Components +1 on SVN +1 on quality, I really think we need to make sure this one runs out of the box as 3.0.0 without sending a 3.0.1 shortly afterwards. do we have sonar for Karaf yet? If so we should link that from the karaf homepage regards, Achim 2011/7/11 Jean-Baptiste Onofré j...@nanthrax.net: Hi all, We should now focus on the Karaf 3.0.0 release. I have a set of proposals to deal with you. 1 - Jira -- As you certainly saw in your mailbox, I started to prepare the Karaf 3.0.0 roadmap. I edited Jira issues to add a fix version and the component. Feel free to review directly the issues associated to the 3.0.0 release (simply search the fix version 3.0.0 in Jira). We have also: - Karaf 3.0.1 - Karaf 3.1.0 where you can move the issues depending of the severity/priority. I would like also to propose some changes in the Jira components. Currently, the Jira components are not very helpful. I think that we need more fine-grained components. I propose: - OBR: all issues related to OBR - Shell: all issues related to shell display and shell commands (it's currently console) - WebConsole: all issues related to the web console - WebContainer: all issues related to the web container, web deployer, Pax-Web - Features: all issues related to Karaf features - WrapDeployer: all issues related to wrap deployer - KAR: all issues related to KAR artifact and deployer - OSGi/Runtime: all issues related to bundle installation, OSGi framework, etc - Cellar: all issues related to Karaf Cellar 2 - Subversion Currently Karaf 3.0.0 is the Karaf trunk. I propose: - to focus on the Jira issues first, that it should be fixed on trunk - release Karaf 3.0.0 - when Karaf 3.0.0 is out, I will create the karaf-3.0.x branch, and the trunk will become Karaf 3.1.0 Is it OK for you ? 3 - Quality -- Karaf 3.0.0 is an important release. It's expected by a lot of people and projects, and for a long time now :) It's really important that we insure the highest quality for this release. It means that I don't wanna rush on this release: I would like that we take a time to make clean code, deep tests, add the unit tests when it's required, etc. So, no rush, we take the time that we need :) Thanks Regards JB -- -- *Achim Nierbeck* Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/; Committer Project Lead
Re: [PROPOSAL] Towards Karaf 3.0.0
Hi JB, +1 for all proposals. Before the 3.0.0 release I think we should do a 3.0.0-RC1 release that people can already test. So I hope we get more feedback for the real 3.0.0. Christian Am 11.07.2011 12:23, schrieb Jean-Baptiste Onofré: Hi all, We should now focus on the Karaf 3.0.0 release. I have a set of proposals to deal with you. 1 - Jira -- As you certainly saw in your mailbox, I started to prepare the Karaf 3.0.0 roadmap. I edited Jira issues to add a fix version and the component. Feel free to review directly the issues associated to the 3.0.0 release (simply search the fix version 3.0.0 in Jira). We have also: - Karaf 3.0.1 - Karaf 3.1.0 where you can move the issues depending of the severity/priority. I would like also to propose some changes in the Jira components. Currently, the Jira components are not very helpful. I think that we need more fine-grained components. I propose: - OBR: all issues related to OBR - Shell: all issues related to shell display and shell commands (it's currently console) - WebConsole: all issues related to the web console - WebContainer: all issues related to the web container, web deployer, Pax-Web - Features: all issues related to Karaf features - WrapDeployer: all issues related to wrap deployer - KAR: all issues related to KAR artifact and deployer - OSGi/Runtime: all issues related to bundle installation, OSGi framework, etc - Cellar: all issues related to Karaf Cellar 2 - Subversion Currently Karaf 3.0.0 is the Karaf trunk. I propose: - to focus on the Jira issues first, that it should be fixed on trunk - release Karaf 3.0.0 - when Karaf 3.0.0 is out, I will create the karaf-3.0.x branch, and the trunk will become Karaf 3.1.0 Is it OK for you ? 3 - Quality -- Karaf 3.0.0 is an important release. It's expected by a lot of people and projects, and for a long time now :) It's really important that we insure the highest quality for this release. It means that I don't wanna rush on this release: I would like that we take a time to make clean code, deep tests, add the unit tests when it's required, etc. So, no rush, we take the time that we need :) Thanks Regards JB -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
Good idea for the RC1. The branch cut off will stand once the RC1 will be approved. Regards JB On Mon 11/07/11 12:43 , Christian Schneider wrote:: Hi JB, +1 for all proposals. Before the 3.0.0 release I think we should do a 3.0.0-RC1 release that people can already test. So I hope we get more feedback for the real 3.0.0. Christian Am 11.07.2011 12:23, schrieb Jean-Baptiste Onofré: Hi all, We should now focus on the Karaf 3.0.0 release. I have a set of proposals to deal with you. 1 - Jira -- As you certainly saw in your mailbox, I started to prepare the Karaf 3.0.0 roadmap. I edited Jira issues to add a fix version and the component. Feel free to review directly the issues associated to the 3.0.0 release (simply search the fix version 3.0.0 in Jira). We have also: - Karaf 3.0.1 - Karaf 3.1.0 where you can move the issues depending of the severity/priority. I would like also to propose some changes in the Jira components. Currently, the Jira components are not very helpful. I think that we need more fine-grained components. I propose: - OBR: all issues related to OBR - Shell: all issues related to shell display and shell commands (it's currently console) - WebConsole: all issues related to the web console - WebContainer: all issues related to the web container, web deployer, Pax-Web - Features: all issues related to Karaf features - WrapDeployer: all issues related to wrap deployer - KAR: all issues related to KAR artifact and deployer - OSGi/Runtime: all issues related to bundle installation, OSGi framework, etc - Cellar: all issues related to Karaf Cellar 2 - Subversion Currently Karaf 3.0.0 is the Karaf trunk. I propose: - to focus on the Jira issues first, that it should be fixed on trunk - release Karaf 3.0.0 - when Karaf 3.0.0 is out, I will create the karaf-3.0.x branch, and the trunk will become Karaf 3.1.0 Is it OK for you ? 3 - Quality -- Karaf 3.0.0 is an important release. It's expected by a lot of people and projects, and for a long time now :) It's really important that we insure the highest quality for this release. It means that I don't wanna rush on this release: I would like that we take a time to make clean code, deep tests, add the unit tests when it's required, etc. So, no rush, we take the time that we need :) Thanks Regards JB -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
+1 for sonar I'd just like to leave a reminder to everyone to watch the hudson builds of trunk: https://builds.apache.org/job/Karaf/ I'd also like to remind everyone to try test builds on as many platforms as possible (HPUX, AIX, Windows) and report any issues encountered. As to an RC1 -- this would be something we just tag from trunk? Cheers, Jamie On Mon, Jul 11, 2011 at 8:13 AM, Christian Schneider ch...@die-schneider.net wrote: Hi JB, +1 for all proposals. Before the 3.0.0 release I think we should do a 3.0.0-RC1 release that people can already test. So I hope we get more feedback for the real 3.0.0. Christian Am 11.07.2011 12:23, schrieb Jean-Baptiste Onofré: Hi all, We should now focus on the Karaf 3.0.0 release. I have a set of proposals to deal with you. 1 - Jira -- As you certainly saw in your mailbox, I started to prepare the Karaf 3.0.0 roadmap. I edited Jira issues to add a fix version and the component. Feel free to review directly the issues associated to the 3.0.0 release (simply search the fix version 3.0.0 in Jira). We have also: - Karaf 3.0.1 - Karaf 3.1.0 where you can move the issues depending of the severity/priority. I would like also to propose some changes in the Jira components. Currently, the Jira components are not very helpful. I think that we need more fine-grained components. I propose: - OBR: all issues related to OBR - Shell: all issues related to shell display and shell commands (it's currently console) - WebConsole: all issues related to the web console - WebContainer: all issues related to the web container, web deployer, Pax-Web - Features: all issues related to Karaf features - WrapDeployer: all issues related to wrap deployer - KAR: all issues related to KAR artifact and deployer - OSGi/Runtime: all issues related to bundle installation, OSGi framework, etc - Cellar: all issues related to Karaf Cellar 2 - Subversion Currently Karaf 3.0.0 is the Karaf trunk. I propose: - to focus on the Jira issues first, that it should be fixed on trunk - release Karaf 3.0.0 - when Karaf 3.0.0 is out, I will create the karaf-3.0.x branch, and the trunk will become Karaf 3.1.0 Is it OK for you ? 3 - Quality -- Karaf 3.0.0 is an important release. It's expected by a lot of people and projects, and for a long time now :) It's really important that we insure the highest quality for this release. It means that I don't wanna rush on this release: I would like that we take a time to make clean code, deep tests, add the unit tests when it's required, etc. So, no rush, we take the time that we need :) Thanks Regards JB -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
Hi JB, Excellent ideas that you propose. Here is some light modifications that propose for your list of components - Repository : All issues related to OBR, Maven, pax mvn configs - Admin : All issues related to 'admin,client,karaf,start,stop' scripts to launch Karaf on W2K, Unix, Mac, SSH, Authenticate/Authorise users, Define log/trace, Debugging, ... - Console : All issues related to shell - commands display - Commands : All issues related to execution commands - Web Console: All issues related to the web console - Web Container: All issues related to the web container, web deployer, Pax-Web - Features: All issues related to Karaf features - Deployer: All issues related to (hot) deployers (wrap, eba, spring, blueprint, bundle, simple jar, kar) - OSGi/Runtime: All issues related to bundle installation, OSGi framework, etc - Cellar: All issues related to Karaf Cellar - Various : All issues related to something else Regards, Charles Moulliard Apache Committer Blog : http://cmoulliard.blogspot.com Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard Skype: cmoulliard On Mon, Jul 11, 2011 at 12:50 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Yes, just a trunk tag is good for the RC1. Regards JB On Mon 11/07/11 12:49 , Jamie G. wrote:: +1 for sonar I'd just like to leave a reminder to everyone to watch the hudson builds of trunk: https://builds.apache.org/job/Karaf/ I'd also like to remind everyone to try test builds on as many platforms as possible (HPUX, AIX, Windows) and report any issues encountered. As to an RC1 -- this would be something we just tag from trunk? Cheers, Jamie On Mon, Jul 11, 2011 at 8:13 AM, Christian Schneider ch...@die-schneider.net wrote: Hi JB, +1 for all proposals. Before the 3.0.0 release I think we should do a 3.0.0-RC1 release that people can already test. So I hope we get more feedback for the real 3.0.0. Christian Am 11.07.2011 12:23, schrieb Jean-Baptiste Onofré: Hi all, We should now focus on the Karaf 3.0.0 release. I have a set of proposals to deal with you. 1 - Jira -- As you certainly saw in your mailbox, I started to prepare the Karaf 3.0.0 roadmap. I edited Jira issues to add a fix version and the component. Feel free to review directly the issues associated to the 3.0.0 release (simply search the fix version 3.0.0 in Jira). We have also: - Karaf 3.0.1 - Karaf 3.1.0 where you can move the issues depending of the severity/priority. I would like also to propose some changes in the Jira components. Currently, the Jira components are not very helpful. I think that we need more fine-grained components. I propose: - OBR: all issues related to OBR - Shell: all issues related to shell display and shell commands (it's currently console) - WebConsole: all issues related to the web console - WebContainer: all issues related to the web container, web deployer, Pax-Web - Features: all issues related to Karaf features - WrapDeployer: all issues related to wrap deployer - KAR: all issues related to KAR artifact and deployer - OSGi/Runtime: all issues related to bundle installation, OSGi framework, etc - Cellar: all issues related to Karaf Cellar 2 - Subversion Currently Karaf 3.0.0 is the Karaf trunk. I propose: - to focus on the Jira issues first, that it should be fixed on trunk - release Karaf 3.0.0 - when Karaf 3.0.0 is out, I will create the karaf-3.0.x branch, and the trunk will become Karaf 3.1.0 Is it OK for you ? 3 - Quality -- Karaf 3.0.0 is an important release. It's expected by a lot of people and projects, and for a long time now :) It's really important that we insure the highest quality for this release. It means that I don't wanna rush on this release: I would like that we take a time to make clean code, deep tests, add the unit tests when it's required, etc. So, no rush, we take the time that we need :) Thanks Regards JB -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
Also a BIG +1 for sonar On Mon, Jul 11, 2011 at 12:35 PM, Achim Nierbeck bcanh...@googlemail.com wrote: Hi JB, thanx for cleaning up Jira and filling up my mailbox ;-) +1 on the road map +1 on the new Jira Components +1 on SVN +1 on quality, I really think we need to make sure this one runs out of the box as 3.0.0 without sending a 3.0.1 shortly afterwards. do we have sonar for Karaf yet? If so we should link that from the karaf homepage regards, Achim 2011/7/11 Jean-Baptiste Onofré j...@nanthrax.net: Hi all, We should now focus on the Karaf 3.0.0 release. I have a set of proposals to deal with you. 1 - Jira -- As you certainly saw in your mailbox, I started to prepare the Karaf 3.0.0 roadmap. I edited Jira issues to add a fix version and the component. Feel free to review directly the issues associated to the 3.0.0 release (simply search the fix version 3.0.0 in Jira). We have also: - Karaf 3.0.1 - Karaf 3.1.0 where you can move the issues depending of the severity/priority. I would like also to propose some changes in the Jira components. Currently, the Jira components are not very helpful. I think that we need more fine-grained components. I propose: - OBR: all issues related to OBR - Shell: all issues related to shell display and shell commands (it's currently console) - WebConsole: all issues related to the web console - WebContainer: all issues related to the web container, web deployer, Pax-Web - Features: all issues related to Karaf features - WrapDeployer: all issues related to wrap deployer - KAR: all issues related to KAR artifact and deployer - OSGi/Runtime: all issues related to bundle installation, OSGi framework, etc - Cellar: all issues related to Karaf Cellar 2 - Subversion Currently Karaf 3.0.0 is the Karaf trunk. I propose: - to focus on the Jira issues first, that it should be fixed on trunk - release Karaf 3.0.0 - when Karaf 3.0.0 is out, I will create the karaf-3.0.x branch, and the trunk will become Karaf 3.1.0 Is it OK for you ? 3 - Quality -- Karaf 3.0.0 is an important release. It's expected by a lot of people and projects, and for a long time now :) It's really important that we insure the highest quality for this release. It means that I don't wanna rush on this release: I would like that we take a time to make clean code, deep tests, add the unit tests when it's required, etc. So, no rush, we take the time that we need :) Thanks Regards JB -- -- *Achim Nierbeck* Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead
Re: [PROPOSAL] Towards Karaf 3.0.0
It makes sense Andreas. I will do that way. Regards JB On Mon 11/07/11 14:10 , Andreas Pieber wrote:: +1 for the extensions; but one open point here: Do we expect that Cellar will create more componnets in the future? In that case I would propose to name the components: karaf-repository karaf-admin karaf-console karaf-commands cellar-hazelcast cellar-console ... since both cellar and karaf are easy to type I don't think that this will create any problems but should make it easier to extend it. WDYT? Kind regards, Andreas On Mon, Jul 11, 2011 at 1:24 PM, Charles Moulliard cmoulli...@gmail.com wrote: Hi JB, Excellent ideas that you propose. Here is some light modifications that propose for your list of components - Repository : All issues related to OBR, Maven, pax mvn configs - Admin : All issues related to 'admin,client,karaf,start,stop' scripts to launch Karaf on W2K, Unix, Mac, SSH, Authenticate/Authorise users, Define log/trace, Debugging, ... - Console : All issues related to shell - commands display - Commands : All issues related to execution commands - Web Console: All issues related to the web console - Web Container: All issues related to the web container, web deployer, Pax-Web - Features: All issues related to Karaf features - Deployer: All issues related to (hot) deployers (wrap, eba, spring, blueprint, bundle, simple jar, kar) - OSGi/Runtime: All issues related to bundle installation, OSGi framework, etc - Cellar: All issues related to Karaf Cellar - Various : All issues related to something else Regards, Charles Moulliard Apache Committer Blog : http://cmoulliard.blogspot.com Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard Skype: cmoulliard On Mon, Jul 11, 2011 at 12:50 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Yes, just a trunk tag is good for the RC1. Regards JB On Mon 11/07/11 12:49 , Jamie G. wrote:: +1 for sonar I'd just like to leave a reminder to everyone to watch the hudson builds of trunk: https://builds.apache.org/job/Karaf/ I'd also like to remind everyone to try test builds on as many platforms as possible (HPUX, AIX, Windows) and report any issues encountered. As to an RC1 -- this would be something we just tag from trunk? Cheers, Jamie On Mon, Jul 11, 2011 at 8:13 AM, Christian Schneider ch...@die-schneider.net wrote: Hi JB, +1 for all proposals. Before the 3.0.0 release I think we should do a 3.0.0-RC1 release that people can already test. So I hope we get more feedback for the real 3.0.0. Christian Am 11.07.2011 12:23, schrieb Jean-Baptiste Onofré: Hi all, We should now focus on the Karaf 3.0.0 release. I have a set of proposals to deal with you. 1 - Jira -- As you certainly saw in your mailbox, I started to prepare the Karaf 3.0.0 roadmap. I edited Jira issues to add a fix version and the component. Feel free to review directly the issues associated to the 3.0.0 release (simply search the fix version 3.0.0 in Jira). We have also: - Karaf 3.0.1 - Karaf 3.1.0 where you can move the issues depending of the severity/priority. I would like also to propose some changes in the Jira components. Currently, the Jira components are not very helpful. I think that we need more fine-grained components. I propose: - OBR: all issues related to OBR - Shell: all issues related to shell display and shell commands (it's currently console) - WebConsole: all issues related to the web console - WebContainer: all issues related to the web container, web deployer, Pax-Web - Features: all issues related to Karaf features - WrapDeployer: all issues related to wrap deployer - KAR: all issues related to KAR artifact and deployer - OSGi/Runtime: all issues related to bundle installation, OSGi framework, etc - Cellar: all issues related to Karaf Cellar 2 - Subversion Currently Karaf 3.0.0 is the Karaf trunk. I propose: - to focus on the Jira issues first, that it should be fixed on trunk - release Karaf 3.0.0 - when Karaf 3.0.0 is out, I will create the karaf-3.0.x branch, and the trunk will become Karaf 3.1.0 Is it OK for you ? 3 - Quality -- Karaf 3.0.0 is an important release. It's expected by a lot of people and projects, and for a long time now :) It's really important that we insure the highest quality for this release. It means that I don't wanna rush on this release: I would like that we take a time to make clean code, deep tests, add the unit tests when it's required, etc. So, no rush, we take the time that we need :) Thanks Regards JB -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
I'm with Andreas here only if the amount of work (Jamie you know best :-) ) is acceptable for a RC that is not only tested from us. Does ServiceMix do a RC yet, is it planned for future releases? Is Geronimo willing to Test with a Karaf RC? Only in that cases I think the work should be put in place. Regards, Achim 2011/7/11 Andreas Pieber anpie...@gmail.com: Basically +1; the only question here: does anybody (except of us on the dev-list) really use/test RCs? If yes +1; otherwise -1 since a releaese (even an RC) is a considerable amount of work Just my 2 cents Kind regards, Andreas On Mon, Jul 11, 2011 at 12:47 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Good idea for the RC1. The branch cut off will stand once the RC1 will be approved. Regards JB On Mon 11/07/11 12:43 , Christian Schneider wrote:: Hi JB, +1 for all proposals. Before the 3.0.0 release I think we should do a 3.0.0-RC1 release that people can already test. So I hope we get more feedback for the real 3.0.0. Christian Am 11.07.2011 12:23, schrieb Jean-Baptiste Onofré: Hi all, We should now focus on the Karaf 3.0.0 release. I have a set of proposals to deal with you. 1 - Jira -- As you certainly saw in your mailbox, I started to prepare the Karaf 3.0.0 roadmap. I edited Jira issues to add a fix version and the component. Feel free to review directly the issues associated to the 3.0.0 release (simply search the fix version 3.0.0 in Jira). We have also: - Karaf 3.0.1 - Karaf 3.1.0 where you can move the issues depending of the severity/priority. I would like also to propose some changes in the Jira components. Currently, the Jira components are not very helpful. I think that we need more fine-grained components. I propose: - OBR: all issues related to OBR - Shell: all issues related to shell display and shell commands (it's currently console) - WebConsole: all issues related to the web console - WebContainer: all issues related to the web container, web deployer, Pax-Web - Features: all issues related to Karaf features - WrapDeployer: all issues related to wrap deployer - KAR: all issues related to KAR artifact and deployer - OSGi/Runtime: all issues related to bundle installation, OSGi framework, etc - Cellar: all issues related to Karaf Cellar 2 - Subversion Currently Karaf 3.0.0 is the Karaf trunk. I propose: - to focus on the Jira issues first, that it should be fixed on trunk - release Karaf 3.0.0 - when Karaf 3.0.0 is out, I will create the karaf-3.0.x branch, and the trunk will become Karaf 3.1.0 Is it OK for you ? 3 - Quality -- Karaf 3.0.0 is an important release. It's expected by a lot of people and projects, and for a long time now :) It's really important that we insure the highest quality for this release. It means that I don't wanna rush on this release: I would like that we take a time to make clean code, deep tests, add the unit tests when it's required, etc. So, no rush, we take the time that we need :) Thanks Regards JB -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- -- *Achim Nierbeck* Apache Karaf http://karaf.apache.org/ Committer PMC OPS4J Pax Web http://wiki.ops4j.org/display/paxweb/Pax+Web/ Committer Project Lead
Re: [PROPOSAL] Towards Karaf 3.0.0
Hi Andreas, The main enhacements for now in Karaf 3.0.0 are: - regex support in all commands - new plugin - renaming of commands I would like to add: - profiles/distribution improvements - shell context Why not adding some others new features, but the corresponding Jira doesn't exist so far :) For now, the roadmap is only the assignation of existing Jira. Feel free to add new :) Regards JB On Mon 11/07/11 14:26 , Andreas Pieber wrote:: Hey, On Mon, Jul 11, 2011 at 12:23 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: 1 - Jira -- As you certainly saw in your mailbox, I started to prepare the Karaf 3.0.0 roadmap. Definitely :) I edited Jira issues to add a fix version and the component. Feel free to review directly the issues associated to the 3.0.0 release (simply search the fix version 3.0.0 in Jira). This may helps: https://issues.apache.org/jira/secure/IssueNavigator!executeAdvanced.jspa project = Karaf AND fixVersion=3.0.0 AND status in (Open, Reopened, In Progress) TBH I'm not too happy with the current roadmap. There are only bug-fixes or minor enhancements which are also backported to 2.x; IMHO we're missing at least 1-2 killer features making it worth for people to upgrade to 3.x. We had various of those topics in the karaf birthday (btw, when will be the next one? This was fun :)) discussion and on our roadmap. By link: * https://cwiki.apache.org/confluence/display/KARAF/Apache+Karaf+First+Birthday+Meeting+%282011-06-16%29 * https://cwiki.apache.org/confluence/display/KARAF/Roadmap By name: * Clustering (ok, this is cellar and already possible on 2.x) * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) * Karaf Enterprise Repository (No issue and no work on this by now) * JDK 1.6 (done) * Tooling dependencies (here is still some work to do (and no issues) * JAAS easy configuration (is it easier by now?) * Improve Karaf development platform * Web Console (I think this is not such a thing for 3.x; I'll provide a prototype for this one with pax-wicket asap pax-wicket reaches 1.0 (latest end auf August I hope) * Karaf Cave OBR (OK, not relevant for 3.x; rather a new subproject) OK, with all of them named I think Karaf-3.0 should at least contain two of the above mentioned features to be REALLY valuable for all people. Considering the threads on related mailinglists (smx, cxf, camel, ...) I think the following two should be definitely in 3.0 (at least for 70% and usable): * Karaf profiles Kar files * Karaf Enterprise Repository WDYT? 2 - Subversion Currently Karaf 3.0.0 is the Karaf trunk. I propose: - to focus on the Jira issues first, that it should be fixed on trunk - release Karaf 3.0.0 - when Karaf 3.0.0 is out, I will create the karaf-3.0.x branch, and the trunk will become Karaf 3.1.0 Is it OK for you ? Nothing to add; +1 3 - Quality -- Karaf 3.0.0 is an important release. It's expected by a lot of people and projects, and for a long time now :) It's really important that we insure the highest quality for this release. It means that I don't wanna rush on this release: I would like that we take a time to make clean code, deep tests, add the unit tests when it's required, etc. So, no rush, we take the time that we need :) +1 to sonar; maybe some quality stats defined we want to reach before 3.0? Kind regards, Andreas
Re: [PROPOSAL] Towards Karaf 3.0.0
FYI, I created/renamed all Jira components. I have also created the low-hanging-fruit label to identify easy-fixable issue :) Regards JB On Mon 11/07/11 14:29 , Jean-Baptiste Onofré wrote:: Hi Andreas, The main enhacements for now in Karaf 3.0.0 are: - regex support in all commands - new plugin - renaming of commands I would like to add: - profiles/distribution improvements - shell context Why not adding some others new features, but the corresponding Jira doesn't exist so far :) For now, the roadmap is only the assignation of existing Jira. Feel free to add new :) Regards JB On Mon 11/07/11 14:26 , Andreas Pieber wrote:: Hey, On Mon, Jul 11, 2011 at 12:23 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: 1 - Jira -- As you certainly saw in your mailbox, I started to prepare the Karaf 3.0.0 roadmap. Definitely :) I edited Jira issues to add a fix version and the component. Feel free to review directly the issues associated to the 3.0.0 release (simply search the fix version 3.0.0 in Jira). This may helps: https://issues.apache.org/jira/secure/IssueNavigator!executeAdvanced.jspa project = Karaf AND fixVersion=3.0.0 AND status in (Open, Reopened, In Progress) TBH I'm not too happy with the current roadmap. There are only bug-fixes or minor enhancements which are also backported to 2.x; IMHO we're missing at least 1-2 killer features making it worth for people to upgrade to 3.x. We had various of those topics in the karaf birthday (btw, when will be the next one? This was fun :)) discussion and on our roadmap. By link: * https://cwiki.apache.org/confluence/display/KARAF/Apache+Karaf+First+Birthday+Meeting+%282011-06-16%29 * https://cwiki.apache.org/confluence/display/KARAF/Roadmap By name: * Clustering (ok, this is cellar and already possible on 2.x) * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) * Karaf Enterprise Repository (No issue and no work on this by now) * JDK 1.6 (done) * Tooling dependencies (here is still some work to do (and no issues) * JAAS easy configuration (is it easier by now?) * Improve Karaf development platform * Web Console (I think this is not such a thing for 3.x; I'll provide a prototype for this one with pax-wicket asap pax-wicket reaches 1.0 (latest end auf August I hope) * Karaf Cave OBR (OK, not relevant for 3.x; rather a new subproject) OK, with all of them named I think Karaf-3.0 should at least contain two of the above mentioned features to be REALLY valuable for all people. Considering the threads on related mailinglists (smx, cxf, camel, ...) I think the following two should be definitely in 3.0 (at least for 70% and usable): * Karaf profiles Kar files * Karaf Enterprise Repository WDYT? 2 - Subversion Currently Karaf 3.0.0 is the Karaf trunk. I propose: - to focus on the Jira issues first, that it should be fixed on trunk - release Karaf 3.0.0 - when Karaf 3.0.0 is out, I will create the karaf-3.0.x branch, and the trunk will become Karaf 3.1.0 Is it OK for you ? Nothing to add; +1 3 - Quality -- Karaf 3.0.0 is an important release. It's expected by a lot of people and projects, and for a long time now :) It's really important that we insure the highest quality for this release. It means that I don't wanna rush on this release: I would like that we take a time to make clean code, deep tests, add the unit tests when it's required, etc. So, no rush, we take the time that we need :) +1 to sonar; maybe some quality stats defined we want to reach before 3.0? Kind regards, Andreas
Re: [PROPOSAL] Towards Karaf 3.0.0
Hi Andreas, I don´t think we need killer features to do a 3.0.0 as we can do feature enhancements in 3.1.0 without any problems. We should instead focus on refactorings that may break code and remove deprecated stuff. These should go into 3.0.0 as we should try to stay compatible in the minor releases that follow. In general I would like to get out 3.0.0 as soon as possible. This can only be done by postponing some feature to 3.1.0. I think this does not hurt much. We need time to create the more complicated features anyway and we can do the 3.1.0 release quite soon. So I think the question is: Will the features you named (profiles, Kar files, enterprise repository) break APIs? If yes they need to go into 3.0.0 or we at least need to change the APIs. If no then I see no need to halt the release as we can put them into 3.1.0. Christian Am 11.07.2011 14:26, schrieb Andreas Pieber: TBH I'm not too happy with the current roadmap. There are only bug-fixes or minor enhancements which are also backported to 2.x; IMHO we're missing at least 1-2 killer features making it worth for people to upgrade to 3.x. We had various of those topics in the karaf birthday (btw, when will be the next one? This was fun :)) discussion and on our roadmap. By link: * https://cwiki.apache.org/confluence/display/KARAF/Apache+Karaf+First+Birthday+Meeting+%282011-06-16%29 * https://cwiki.apache.org/confluence/display/KARAF/Roadmap By name: * Clustering (ok, this is cellar and already possible on 2.x) * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) * Karaf Enterprise Repository (No issue and no work on this by now) * JDK 1.6 (done) * Tooling dependencies (here is still some work to do (and no issues) * JAAS easy configuration (is it easier by now?) * Improve Karaf development platform * Web Console (I think this is not such a thing for 3.x; I'll provide a prototype for this one with pax-wicket asap pax-wicket reaches 1.0 (latest end auf August I hope) * Karaf Cave OBR (OK, not relevant for 3.x; rather a new subproject) OK, with all of them named I think Karaf-3.0 should at least contain two of the above mentioned features to be REALLY valuable for all people. Considering the threads on related mailinglists (smx, cxf, camel, ...) I think the following two should be definitely in 3.0 (at least for 70% and usable): * Karaf profiles Kar files * Karaf Enterprise Repository WDYT? -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
I think adding two more features to 3.0.0 then going for an RC makes sense. As to an early RC that is not intended to be a 'true' release candidate, I'm game to produce one if we think it'll help with adoption/testing for the real 3.0.0. Cheers, Jamie On Mon, Jul 11, 2011 at 10:49 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Christian, I'm agree with both of you :) We are going to release Karaf 3.0.0, not Karaf 2.3. It means that the end-users expect some new features in Karaf 3.0.0. I'm agree with Andreas to add two main enhancements/new features in Karaf 3.0.0. But, as you rightly said, we also need to focus on the code cleanup. I propose to choose two enhancements to be included in Karaf 3.0.0, and postpone the others to 3.1.0. Regards JB On Mon 11/07/11 15:16 , Christian Schneider wrote:: Hi Andreas, I don´t think we need killer features to do a 3.0.0 as we can do feature enhancements in 3.1.0 without any problems. We should instead focus on refactorings that may break code and remove deprecated stuff. These should go into 3.0.0 as we should try to stay compatible in the minor releases that follow. In general I would like to get out 3.0.0 as soon as possible. This can only be done by postponing some feature to 3.1.0. I think this does not hurt much. We need time to create the more complicated features anyway and we can do the 3.1.0 release quite soon. So I think the question is: Will the features you named (profiles, Kar files, enterprise repository) break APIs? If yes they need to go into 3.0.0 or we at least need to change the APIs. If no then I see no need to halt the release as we can put them into 3.1.0. Christian Am 11.07.2011 14:26, schrieb Andreas Pieber: TBH I'm not too happy with the current roadmap. There are only bug-fixes or minor enhancements which are also backported to 2.x; IMHO we're missing at least 1-2 killer features making it worth for people to upgrade to 3.x. We had various of those topics in the karaf birthday (btw, when will be the next one? This was fun :)) discussion and on our roadmap. By link: * https://cwiki.apache.org/confluence/display/KARAF/Apache+Karaf+First+Birthday+Meeting+%282011-06-16%29 * https://cwiki.apache.org/confluence/display/KARAF/Roadmap By name: * Clustering (ok, this is cellar and already possible on 2.x) * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) * Karaf Enterprise Repository (No issue and no work on this by now) * JDK 1.6 (done) * Tooling dependencies (here is still some work to do (and no issues) * JAAS easy configuration (is it easier by now?) * Improve Karaf development platform * Web Console (I think this is not such a thing for 3.x; I'll provide a prototype for this one with pax-wicket asap pax-wicket reaches 1.0 (latest end auf August I hope) * Karaf Cave OBR (OK, not relevant for 3.x; rather a new subproject) OK, with all of them named I think Karaf-3.0 should at least contain two of the above mentioned features to be REALLY valuable for all people. Considering the threads on related mailinglists (smx, cxf, camel, ...) I think the following two should be definitely in 3.0 (at least for 70% and usable): * Karaf profiles Kar files * Karaf Enterprise Repository WDYT? -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
@RC again; I'm definitely with Achim here (except that you really like to do the work Jamie :)) that we may ping the smx/geronimo communities to also provide snapshots of their products based on karaf_RC. that way the work will really pay off since we'll get tons of more user feedback (I assume) than simply do this for karaf alone (there are ways less projects depending on karaf directly I assume; comparing the download volume of SMX to karaf :)) Kind regards, Andreas On Mon, Jul 11, 2011 at 3:30 PM, Jamie G. jamie.goody...@gmail.com wrote: I think adding two more features to 3.0.0 then going for an RC makes sense. As to an early RC that is not intended to be a 'true' release candidate, I'm game to produce one if we think it'll help with adoption/testing for the real 3.0.0. Cheers, Jamie On Mon, Jul 11, 2011 at 10:49 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Christian, I'm agree with both of you :) We are going to release Karaf 3.0.0, not Karaf 2.3. It means that the end-users expect some new features in Karaf 3.0.0. I'm agree with Andreas to add two main enhancements/new features in Karaf 3.0.0. But, as you rightly said, we also need to focus on the code cleanup. I propose to choose two enhancements to be included in Karaf 3.0.0, and postpone the others to 3.1.0. Regards JB On Mon 11/07/11 15:16 , Christian Schneider wrote:: Hi Andreas, I don´t think we need killer features to do a 3.0.0 as we can do feature enhancements in 3.1.0 without any problems. We should instead focus on refactorings that may break code and remove deprecated stuff. These should go into 3.0.0 as we should try to stay compatible in the minor releases that follow. In general I would like to get out 3.0.0 as soon as possible. This can only be done by postponing some feature to 3.1.0. I think this does not hurt much. We need time to create the more complicated features anyway and we can do the 3.1.0 release quite soon. So I think the question is: Will the features you named (profiles, Kar files, enterprise repository) break APIs? If yes they need to go into 3.0.0 or we at least need to change the APIs. If no then I see no need to halt the release as we can put them into 3.1.0. Christian Am 11.07.2011 14:26, schrieb Andreas Pieber: TBH I'm not too happy with the current roadmap. There are only bug-fixes or minor enhancements which are also backported to 2.x; IMHO we're missing at least 1-2 killer features making it worth for people to upgrade to 3.x. We had various of those topics in the karaf birthday (btw, when will be the next one? This was fun :)) discussion and on our roadmap. By link: * https://cwiki.apache.org/confluence/display/KARAF/Apache+Karaf+First+Birthday+Meeting+%282011-06-16%29 * https://cwiki.apache.org/confluence/display/KARAF/Roadmap By name: * Clustering (ok, this is cellar and already possible on 2.x) * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) * Karaf Enterprise Repository (No issue and no work on this by now) * JDK 1.6 (done) * Tooling dependencies (here is still some work to do (and no issues) * JAAS easy configuration (is it easier by now?) * Improve Karaf development platform * Web Console (I think this is not such a thing for 3.x; I'll provide a prototype for this one with pax-wicket asap pax-wicket reaches 1.0 (latest end auf August I hope) * Karaf Cave OBR (OK, not relevant for 3.x; rather a new subproject) OK, with all of them named I think Karaf-3.0 should at least contain two of the above mentioned features to be REALLY valuable for all people. Considering the threads on related mailinglists (smx, cxf, camel, ...) I think the following two should be definitely in 3.0 (at least for 70% and usable): * Karaf profiles Kar files * Karaf Enterprise Repository WDYT? -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
Let's just say I have a bottle of wine that i'd like to decant in the near future ;) On Mon, Jul 11, 2011 at 11:16 AM, Andreas Pieber anpie...@gmail.com wrote: @RC again; I'm definitely with Achim here (except that you really like to do the work Jamie :)) that we may ping the smx/geronimo communities to also provide snapshots of their products based on karaf_RC. that way the work will really pay off since we'll get tons of more user feedback (I assume) than simply do this for karaf alone (there are ways less projects depending on karaf directly I assume; comparing the download volume of SMX to karaf :)) Kind regards, Andreas On Mon, Jul 11, 2011 at 3:30 PM, Jamie G. jamie.goody...@gmail.com wrote: I think adding two more features to 3.0.0 then going for an RC makes sense. As to an early RC that is not intended to be a 'true' release candidate, I'm game to produce one if we think it'll help with adoption/testing for the real 3.0.0. Cheers, Jamie On Mon, Jul 11, 2011 at 10:49 AM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi Christian, I'm agree with both of you :) We are going to release Karaf 3.0.0, not Karaf 2.3. It means that the end-users expect some new features in Karaf 3.0.0. I'm agree with Andreas to add two main enhancements/new features in Karaf 3.0.0. But, as you rightly said, we also need to focus on the code cleanup. I propose to choose two enhancements to be included in Karaf 3.0.0, and postpone the others to 3.1.0. Regards JB On Mon 11/07/11 15:16 , Christian Schneider wrote:: Hi Andreas, I don´t think we need killer features to do a 3.0.0 as we can do feature enhancements in 3.1.0 without any problems. We should instead focus on refactorings that may break code and remove deprecated stuff. These should go into 3.0.0 as we should try to stay compatible in the minor releases that follow. In general I would like to get out 3.0.0 as soon as possible. This can only be done by postponing some feature to 3.1.0. I think this does not hurt much. We need time to create the more complicated features anyway and we can do the 3.1.0 release quite soon. So I think the question is: Will the features you named (profiles, Kar files, enterprise repository) break APIs? If yes they need to go into 3.0.0 or we at least need to change the APIs. If no then I see no need to halt the release as we can put them into 3.1.0. Christian Am 11.07.2011 14:26, schrieb Andreas Pieber: TBH I'm not too happy with the current roadmap. There are only bug-fixes or minor enhancements which are also backported to 2.x; IMHO we're missing at least 1-2 killer features making it worth for people to upgrade to 3.x. We had various of those topics in the karaf birthday (btw, when will be the next one? This was fun :)) discussion and on our roadmap. By link: * https://cwiki.apache.org/confluence/display/KARAF/Apache+Karaf+First+Birthday+Meeting+%282011-06-16%29 * https://cwiki.apache.org/confluence/display/KARAF/Roadmap By name: * Clustering (ok, this is cellar and already possible on 2.x) * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) * Karaf Enterprise Repository (No issue and no work on this by now) * JDK 1.6 (done) * Tooling dependencies (here is still some work to do (and no issues) * JAAS easy configuration (is it easier by now?) * Improve Karaf development platform * Web Console (I think this is not such a thing for 3.x; I'll provide a prototype for this one with pax-wicket asap pax-wicket reaches 1.0 (latest end auf August I hope) * Karaf Cave OBR (OK, not relevant for 3.x; rather a new subproject) OK, with all of them named I think Karaf-3.0 should at least contain two of the above mentioned features to be REALLY valuable for all people. Considering the threads on related mailinglists (smx, cxf, camel, ...) I think the following two should be definitely in 3.0 (at least for 70% and usable): * Karaf profiles Kar files * Karaf Enterprise Repository WDYT? -- -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
Re: [PROPOSAL] Towards Karaf 3.0.0
Mike I agree with you besides one point. How do you tell people that this certain version of the SNAPSHOT is the desired version you are supposed to test with. So you are back at a released RC with all the extra efforts of the std. release process but also with the nice thing that Jamie is able to open another bottle of wine here ;-) So unless someone points out that we don't have the std. release cycle for a ReleaseCandidate with the 72hour vote to pass etc. I'm also -1 here Regards, Achim Am 11.07.2011 18:01, schrieb mikevan: +1 (non-binding on all of the items being discussed for a Karaf 3.0 release) -1 for doing a RC release. None of my users will use that, and the time it would take to do an RC is more than we need. My suggestion is that we simply tag/branch a 3.0 release, test it, and then if folks need to make fixes we apply them to the tag/branch the merging them into the trunk. Andreas Pieber wrote: @RC again; I'm definitely with Achim here (except that you really like to do the work Jamie :)) that we may ping the smx/geronimo communities to also provide snapshots of their products based on karaf_RC. that way the work will really pay off since we'll get tons of more user feedback (I assume) than simply do this for karaf alone (there are ways less projects depending on karaf directly I assume; comparing the download volume of SMX to karaf :)) Kind regards, Andreas On Mon, Jul 11, 2011 at 3:30 PM, Jamie G. lt;jamie.goody...@gmail.comgt; wrote: I think adding two more features to 3.0.0 then going for an RC makes sense. As to an early RC that is not intended to be a 'true' release candidate, I'm game to produce one if we think it'll help with adoption/testing for the real 3.0.0. Cheers, Jamie On Mon, Jul 11, 2011 at 10:49 AM, Jean-Baptiste Onofré lt;j...@nanthrax.netgt; wrote: Hi Christian, I'm agree with both of you :) We are going to release Karaf 3.0.0, not Karaf 2.3. It means that the end-users expect some new features in Karaf 3.0.0. I'm agree with Andreas to add two main enhancements/new features in Karaf 3.0.0. But, as you rightly said, we also need to focus on the code cleanup. I propose to choose two enhancements to be included in Karaf 3.0.0, and postpone the others to 3.1.0. Regards JB On Mon 11/07/11 15:16 , Christian Schneider wrote:: Hi Andreas, I don´t think we need killer features to do a 3.0.0 as we can do feature enhancements in 3.1.0 without any problems. We should instead focus on refactorings that may break code and remove deprecated stuff. These should go into 3.0.0 as we should try to stay compatible in the minor releases that follow. In general I would like to get out 3.0.0 as soon as possible. This can only be done by postponing some feature to 3.1.0. I think this does not hurt much. We need time to create the more complicated features anyway and we can do the 3.1.0 release quite soon. So I think the question is: Will the features you named (profiles, Kar files, enterprise repository) break APIs? If yes they need to go into 3.0.0 or we at least need to change the APIs. If no then I see no need to halt the release as we can put them into 3.1.0. Christian Am 11.07.2011 14:26, schrieb Andreas Pieber: TBH I'm not too happy with the current roadmap. There are only bug-fixes or minor enhancements which are also backported to 2.x; IMHO we're missing at least 1-2 killer features making it worth for people to upgrade to 3.x. We had various of those topics in the karaf birthday (btw, when will be the next one? This was fun :)) discussion and on our roadmap. By link: * https://cwiki.apache.org/confluence/display/KARAF/Apache+Karaf+First+Birthday+Meeting+%282011-06-16%29 * https://cwiki.apache.org/confluence/display/KARAF/Roadmap By name: * Clustering (ok, this is cellar and already possible on 2.x) * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) * Karaf Enterprise Repository (No issue and no work on this by now) * JDK 1.6 (done) * Tooling dependencies (here is still some work to do (and no issues) * JAAS easy configuration (is it easier by now?) * Improve Karaf development platform * Web Console (I think this is not such a thing for 3.x; I'll provide a prototype for this one with pax-wicket asap pax-wicket reaches 1.0 (latest end auf August I hope) * Karaf Cave OBR (OK, not relevant for 3.x; rather a new subproject) OK, with all of them named I think Karaf-3.0 should at least contain two of the above mentioned features to be REALLY valuable for all people. Considering the threads on related mailinglists (smx, cxf, camel, ...) I think the following two should be definitely in 3.0 (at least for 70% and usable): * Karaf profiles Kar files * Karaf
Re: [PROPOSAL] Towards Karaf 3.0.0
Hi, Regarding to the content of the release 3.0.0, we should provide not a small enhancement based on Karaf 2.x but a real evolution to move Karaf into a new area. Doing code cleanup + adding more tests cases + web site revamping + documentation improvement will be a big achievement but we must deliver new interesting features for target projects using it : ServiceMix, Geronimo, ... That means that we must in this release : - Simplify the deployment process of the different archives (EAR, WAR, EBA, JAR, KAR, Spring, Blueprint) and help our end users for doing that through Maven, OBR, ... - Question : Do we have to support all of them ? Maybe we could restrict the deployment of the required type (JAR, Bundle, Spring, Blueprint, WAR ?) and let's project like Geronimo to take care about EAR, EJB modules ? - Provide a more Enterprise Web Console for operating Karaf - configuring DataSource(s), web modules, Security, ... - Add admin profile to restrict usage of the Karaf commands as we only support right now a full admin access - Improve and refactor commands like also the display- e.g. when we display all commands -- should be grouped and separate from each other, shortcut displayed at the end, ... - Provide the strategy to be used to perform unit test/integration with Karaf using pax-exam, pax-exam-2, or any other solution allowing to mock OSGI platform - Provide repository of enterprise features (Hibernate, EJB, ...) or at least governance rules to allow third party projects to develop such features and pass them into a acceptance program to certified them according to Karaf releases. + 1 for JB propositions + mine improvements of components + 1 for a Karaf 3.0 release proposing more enterprise features - for RC Regards, Charles Moulliard Apache Committer Blog : http://cmoulliard.blogspot.com Twitter : http://twitter.com/cmoulliard Linkedin : http://www.linkedin.com/in/charlesmoulliard Skype: cmoulliard On Tue, Jul 12, 2011 at 12:05 AM, David Jencks david_jen...@yahoo.com wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: big snip * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and standard assemblies created using kars/features rather than the old style maven-assembly-plugin. I haven't been able to work on this for a while but i thought I left it in a state as least as functional as the old-style servers. The only bit I recall as missing is the legal files. What are you looking for to start e.g. cxf? IIRC you can assemble a server including a cxf feature as a boot feature, or add it in later as a regular feature thanks david jencks
Re: [PROPOSAL] Towards Karaf 3.0.0
Hey David, The problem isn't during assambling but to install e.g. CXF afterwards. Please start an empty Karaf 3.x and try to install the CXF features file. To make it run you have to modify the jre.properties and the bootdelegation to get it up running. And there is no way to do this automatically from your .kar/features.xml right now :( Kind regards, Andreas On Tue, Jul 12, 2011 at 12:05 AM, David Jencks david_jen...@yahoo.com wrote: On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote: big snip * Karaf profiles Kar files (IMHO this is one of the most important features for 3.x and not present in the issues by now; there had been considerable work on this by David, but still, we're missing a possibility to start e.g. CXF without modifying some files in etc) I'm really hoping that 3.0.0 will have the minimal and standard assemblies created using kars/features rather than the old style maven-assembly-plugin. I haven't been able to work on this for a while but i thought I left it in a state as least as functional as the old-style servers. The only bit I recall as missing is the legal files. What are you looking for to start e.g. cxf? IIRC you can assemble a server including a cxf feature as a boot feature, or add it in later as a regular feature thanks david jencks
