Re: EIK support for Karaf 3.0.x and Eclipse Kepler
Hi Simon, oh yes, I will probably publish a couple of EIK SNAPSHOTs, if you can test it, it would be great. Thanks ! Regards JB On 2014-02-04 00:16, siwatson wrote: Hi JB, Absolutely no apology needed. I only have to look at the number of replies you write on this forum to realise how busy you are! If you are able to find some time to review the status of EIK then I would be very grateful and I think it would be useful to other developers. If I can help you test any new snapshot releases then please just let me know. Thanks, Simon. -- View this message in context: http://karaf.922171.n3.nabble.com/EIK-support-for-Karaf-3-0-x-and-Eclipse-Kepler-tp4031500p4031503.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: EIK support for Karaf 3.0.x and Eclipse Kepler
Hi JB, Absolutely no apology needed. I only have to look at the number of replies you write on this forum to realise how busy you are! If you are able to find some time to review the status of EIK then I would be very grateful and I think it would be useful to other developers. If I can help you test any new snapshot releases then please just let me know. Thanks, Simon. -- View this message in context: http://karaf.922171.n3.nabble.com/EIK-support-for-Karaf-3-0-x-and-Eclipse-Kepler-tp4031500p4031503.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [PROPOSAL] Release Karaf 2.3.4 end of this week, 2.4.0 next week ?
Has anyone else experienced "[ERROR] Failed to execute goal on project org.apache.karaf.shell.console: Could not resolve dependencies for project org.apache.karaf.shell:org.apache.karaf.shell.console:bundle:2.3.4-SNAPSHOT: Could not find artifact org.eclipse.osgi:org.eclipse.osgi:jar:3.7.0.v20110124-0830 in servicemix ( http://svn.apache.org/repos/asf/servicemix/m2-repo) -> [Help 1]" While building Karaf 2.3.4-snapshot? Checking http://svn.apache.org/repos/asf/servicemix/m2-repo/org/eclipse/osgi/ version 3.7.0.v20110124 does not appear to be available. My local and release server builds have the above resource already in their local m2, my CI farm however have unpopulated m2s hence catching the issue. --Jamie On Wed, Jan 8, 2014 at 8:20 AM, Bengt Rodehav wrote: > Perfect - looking forward to it! > > /Bengt > > > 2014/1/8 Jean-Baptiste Onofré > > > It's already done and will be included in the next releases. > > > > Same for utils. For Felix ConfigAdmin, I'm checking the impacts. > > > > Regards > > JB > > > > > > On 01/08/2014 12:07 PM, Bengt Rodehav wrote: > > > >> Guillaume has released a new version of FileInstall (3.2.8) that I would > >> love to be included in these versions of Karaf. Is that possible? > >> > >> See: > >> > >> http://apache-felix.18485.x6.nabble.com/VOTE-Release-Utils- > >> 1-4-2-and-FileInstall-3-2-8-td5006385.html > >> > >> /Bengt > >> > >> > >> 2014/1/7 Charles Moulliard > >> > >> +1 > >>> > >>> > >>> On Tue, Jan 7, 2014 at 1:10 AM, Freeman Fang > >>> wrote: > >>> > >>> +1 > － > Freeman(Yue) Fang > > Red Hat, Inc. > FuseSource is now part of Red Hat > > > > On 2014-1-6, at 下午5:34, Jean-Baptiste Onofré wrote: > > Hi guys, > > > > I started to work on Jira for 2.3.4 and 2.4.0. > > > > As we released 2.3.3 in September, I think it's the good time to > > > release > >>> > a 2.3.4 maintenance release. > > > > > WDYT ? > > > > Regards > > JB > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > > > > > >>> > >>> -- > >>> Charles Moulliard > >>> Apache Committer / Architect @RedHat > >>> Twitter : @cmoulliard | Blog : http://cmoulliard.github.io > >>> > >>> > >> > > -- > > Jean-Baptiste Onofré > > jbono...@apache.org > > http://blog.nanthrax.net > > Talend - http://www.talend.com > > >
Re: EIK support for Karaf 3.0.x and Eclipse Kepler
Hi Simon, It's my fault, I'm late on EIK release (busy with some releases, and fixes). I will review your Jira later today and tomorrow. I will keep you posted. Don't hesitate to ping me, please. Regards JB On 2014-02-03 20:19, siwatson wrote: Hi, I posted this to the users list last week but didn't get any feedback, and maybe it's better suited to the dev list anyway... I'm hoping to migrate from Eclipse Virgo to Apache Karaf. Until now, we've relied on Virgo's Eclipse IDE tooling to create bundles and deploy to a local dev server, giving a quick compile-run-debug lifecycle within the IDE. Looking at Karaf, I see there is an EIK project which seems to offer similar functionality. I've tried the 0.9 build and some 0.10 snapshots from early January but I'm unable to get it working with the latest versions of Karaf and/or Eclipse. I don't really want to downgrade to get the tools work if I can help it. I've raised a couple of JIRAs and can see there are a few others in a similar situation. I can appreciate that EIK probably isn't the top priority for the developers so I just wanted to ask if there's a plan for addressing these issues and creating a new release anytime soon? Thanks, Simon. -- View this message in context: http://karaf.922171.n3.nabble.com/EIK-support-for-Karaf-3-0-x-and-Eclipse-Kepler-tp4031500.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
EIK support for Karaf 3.0.x and Eclipse Kepler
Hi, I posted this to the users list last week but didn't get any feedback, and maybe it's better suited to the dev list anyway... I'm hoping to migrate from Eclipse Virgo to Apache Karaf. Until now, we've relied on Virgo's Eclipse IDE tooling to create bundles and deploy to a local dev server, giving a quick compile-run-debug lifecycle within the IDE. Looking at Karaf, I see there is an EIK project which seems to offer similar functionality. I've tried the 0.9 build and some 0.10 snapshots from early January but I'm unable to get it working with the latest versions of Karaf and/or Eclipse. I don't really want to downgrade to get the tools work if I can help it. I've raised a couple of JIRAs and can see there are a few others in a similar situation. I can appreciate that EIK probably isn't the top priority for the developers so I just wanted to ask if there's a plan for addressing these issues and creating a new release anytime soon? Thanks, Simon. -- View this message in context: http://karaf.922171.n3.nabble.com/EIK-support-for-Karaf-3-0-x-and-Eclipse-Kepler-tp4031500.html Sent from the Karaf - Dev mailing list archive at Nabble.com.
Re: [DISCUSS] Migration to SCR
As I mentioned earlier, I am not really interested in the release version per se, but primary in the time to market and secondarily on what it means in terms of maintenance. As in all things, the key is balance. Release often is guaranteed way of delivering value to users, releasing too often may send out the wrong message (is it just me, or people tend to become uneasy with very often major releases?). Also releasing very often means, that as a community we will be supporting each major release for a small period of time, or we will need to increase the number of major versions we support at any given time. Do we have the luxury to do so? For example, let's assume that we go for a 4.x in say 3 months It has proven a bit hard to maintain the long living 3.x branch along with 2.x (module restructures made it not trivial to just cherry-pick fixes from one branch to the other). If we add a third branch into the mix, it will become even harder. So what are we supposed to do here? Push the release back 6 - 12 months, or until we decide we no longer need to support 2.x? In that case we could hold of creating a 4.x branch until we get near that time (to avoid the maintenance overhead). We could use this time and follow Dan's suggestion about letting other projects adopt the feature changes. But still it does sound like a long time which is meant to become even longer as "new features" will pile up for 4.x. Thoughts? -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: [DISCUSS] Migration to SCR
So, start 4.x now! :) Release early, release often. On Mon, Feb 3, 2014 at 12:09 PM, wrote: > Good points Ioannis, > > my point is just about the "message" for we send to the users and community. > > You are right, it took long time to release Karaf 3.0.0, but it doesn't mean > that it would be the same for 4.0.0. > > My point is just to send a message for users/community like: "hey, we did > deep changes" ;) > > Regards > JB > > > On 2014-02-03 16:24, Ioannis Canellos wrote: >>> >>> I would plan this for Karaf 4.0.0, even if it's internal. >> >> >> While I don't have a strong objection on having it as part of a 4.x >> release, that would mean that it will get pushed back way into the >> future. >> 3.x release took us almost 3 years to get out and we stalled 2.3.x for >> 1.5 year in favour of 3.x. >> >> What I take from that experience, is that its not a good idea to push >> stuff to major releases, when they are candidates for a major release. >> >>> It's an important jump internally in Karaf, and should be addressed in a >>> major release. >> >> >> I agree that this is an important change. Semantic versioning doesn't >> force us to push "important" changes to major releases. Since we are >> talking about a change that is transparent to the user, the importance >> of the change is a good reason to deliver it asap :-) >> >>> We just release Karaf 3.0.0, and we have to let people and other projects >>> to >>> move smoothly (even if as you said, you should not have impact). >> >> >> This is another good reason, for not rushing a 4.x release.
Re: [DISCUSS] Migration to SCR
Good points Ioannis, my point is just about the "message" for we send to the users and community. You are right, it took long time to release Karaf 3.0.0, but it doesn't mean that it would be the same for 4.0.0. My point is just to send a message for users/community like: "hey, we did deep changes" ;) Regards JB On 2014-02-03 16:24, Ioannis Canellos wrote: I would plan this for Karaf 4.0.0, even if it's internal. While I don't have a strong objection on having it as part of a 4.x release, that would mean that it will get pushed back way into the future. 3.x release took us almost 3 years to get out and we stalled 2.3.x for 1.5 year in favour of 3.x. What I take from that experience, is that its not a good idea to push stuff to major releases, when they are candidates for a major release. It's an important jump internally in Karaf, and should be addressed in a major release. I agree that this is an important change. Semantic versioning doesn't force us to push "important" changes to major releases. Since we are talking about a change that is transparent to the user, the importance of the change is a good reason to deliver it asap :-) We just release Karaf 3.0.0, and we have to let people and other projects to move smoothly (even if as you said, you should not have impact). This is another good reason, for not rushing a 4.x release.
Re: [DISCUSS] Migration to SCR
> I would plan this for Karaf 4.0.0, even if it's internal. While I don't have a strong objection on having it as part of a 4.x release, that would mean that it will get pushed back way into the future. 3.x release took us almost 3 years to get out and we stalled 2.3.x for 1.5 year in favour of 3.x. What I take from that experience, is that its not a good idea to push stuff to major releases, when they are candidates for a major release. > It's an important jump internally in Karaf, and should be addressed in a > major release. I agree that this is an important change. Semantic versioning doesn't force us to push "important" changes to major releases. Since we are talking about a change that is transparent to the user, the importance of the change is a good reason to deliver it asap :-) > We just release Karaf 3.0.0, and we have to let people and other projects to > move smoothly (even if as you said, you should not have impact). This is another good reason, for not rushing a 4.x release. -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Re: [DISCUSS] Migration to SCR
I would do #2 first, even in the next patch releases. Having the feature defined doesn’t cause any problems at all and that way external projects can start relying on it, even if it is installed by default. Dan On Feb 3, 2014, at 9:52 AM, Ioannis Canellos wrote: > A while back we discussed about migration from Blueprint to SCR and we > all agreed that it was a nice thing to do. > The question is how to do it, without making maintenance hard and also > without taking ages to deliver this new feature. > > I think that this should be done in 3 steps: > > i) Migrate from Blueprint to SCR. > ii) Define features for "Aries Blueprint" > iii) Make Blueprint Optional. > > The first step could be done as part of a Karaf 3.1.0 release. Since > all changes are internal and the only thing that would be required is > to install SCR by default, it doesn't have to be a major release (in > fact it could even be a micro release). The benefit of this approach > is that we will not have to maintain an other branch that would > require extra maintenance, until we are ready for step (ii). > > Once we have SCR in our Karaf 3 branch, we can define features for > aries blueprint and wait for the rest of the projects of the eco > system to pickup those features, were necessary. > > When camel, cxf, activemq have picked up the changes in our features > and have performed a release or two, we can proceed to the final step > and have Blueprint not installed by default > > Thoughts? > > -- > Ioannis Canellos > > Blog: http://iocanel.blogspot.com > Twitter: iocanel -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Migration to SCR
-1 I would plan this for Karaf 4.0.0, even if it's internal. It's an important jump internally in Karaf, and should be addressed in a major release. We just release Karaf 3.0.0, and we have to let people and other projects to move smoothly (even if as you said, you should not have impact). Regards JB On 02/03/2014 03:52 PM, Ioannis Canellos wrote: A while back we discussed about migration from Blueprint to SCR and we all agreed that it was a nice thing to do. The question is how to do it, without making maintenance hard and also without taking ages to deliver this new feature I think that this should be done in 3 steps:1 i) Migrate from Blueprint to SCR. ii) Define features for "Aries Blueprint" iii) Make Blueprint Optional. The first step could be done as part of a Karaf 3.1.0 release. Since all changes are internal and the only thing that would be required is to install SCR by default, it doesn't have to be a major release (in fact it could even be a micro release). The benefit of this approach is that we will not have to maintain an other branch that would require extra maintenance, until we are ready for step (ii). Once we have SCR in our Karaf 3 branch, we can define features for aries blueprint and wait for the rest of the projects of the eco system to pickup those features, were necessary. When camel, cxf, activemq have picked up the changes in our features and have performed a release or two, we can proceed to the final step and have Blueprint not installed by default Thoughts? -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
[DISCUSS] Migration to SCR
A while back we discussed about migration from Blueprint to SCR and we all agreed that it was a nice thing to do. The question is how to do it, without making maintenance hard and also without taking ages to deliver this new feature. I think that this should be done in 3 steps: i) Migrate from Blueprint to SCR. ii) Define features for "Aries Blueprint" iii) Make Blueprint Optional. The first step could be done as part of a Karaf 3.1.0 release. Since all changes are internal and the only thing that would be required is to install SCR by default, it doesn't have to be a major release (in fact it could even be a micro release). The benefit of this approach is that we will not have to maintain an other branch that would require extra maintenance, until we are ready for step (ii). Once we have SCR in our Karaf 3 branch, we can define features for aries blueprint and wait for the rest of the projects of the eco system to pickup those features, were necessary. When camel, cxf, activemq have picked up the changes in our features and have performed a release or two, we can proceed to the final step and have Blueprint not installed by default Thoughts? -- Ioannis Canellos Blog: http://iocanel.blogspot.com Twitter: iocanel
Issues with Attachments: week of 2014-02-03
KARAF - Monday, February 3, 2014 18 Issues with Attachments (sorted oldest to newest) [KARAF-222] Provide karaf:run, karaf:deploy, karaf:client Maven goals (2010-09-25 - New Feature - james strachan) https://issues.apache.org/jira/browse/KARAF-222 [KARAF-1027] Have cave:update-repository work with proxy repositories (2011-11-20 - Improvement - Glen Mazza) https://issues.apache.org/jira/browse/KARAF-1027 [KARAF-1056] Enhancements to cave:upload-artifact command (2011-11-28 - Improvement - Glen Mazza) https://issues.apache.org/jira/browse/KARAF-1056 [KARAF-1166] karaf-maven-plugin pom.xml has missing dependencies (2012-01-19 - Bug - Nicolai Guba) https://issues.apache.org/jira/browse/KARAF-1166 [KARAF-1545] Jar files in lib directory require "karaf-" prefix in order to be loaded (2012-06-13 - Bug - James Carman) https://issues.apache.org/jira/browse/KARAF-1545 [KARAF-1560] config:update throws ClassCastException when used on a Configuration with boolean fields created in the web console (2012-06-18 - Bug - Hugh Rodgers) https://issues.apache.org/jira/browse/KARAF-1560 [KARAF-1701] Parsing of config for a field with cardinality > 1 is incorrectlyprocessed and displayed on Admin Console (2012-08-01 - Bug - Hugh Rodgers) https://issues.apache.org/jira/browse/KARAF-1701 [KARAF-1894] Framework's active start level is set to org.osgi.framework.startlevel.beginning too early when launching Karaf with empty bundle cache (2012-10-03 - Bug - Jason Montojo) https://issues.apache.org/jira/browse/KARAF-1894 [KARAF-1972] karaf-maven-plugin should respect scope (2012-10-24 - Bug - Andrei Pozolotin) https://issues.apache.org/jira/browse/KARAF-1972 [KARAF-2095] Camel Route (JMS Polling) not working when installing feature "jndi" (2013-01-02 - Bug - Shrish Srivastava) https://issues.apache.org/jira/browse/KARAF-2095 [KARAF-2110] karaf-maven-plugin fails to use features with bundles with "wrap" keyword (2013-01-14 - Bug - Konrad Hoszowski) https://issues.apache.org/jira/browse/KARAF-2110 [KARAF-2121] Add Support For Displaying Gogo Commands in Karaf Shell Help (2013-01-17 - New Feature - Gareth Collins) https://issues.apache.org/jira/browse/KARAF-2121 [KARAF-2395] karaf:features-generate-descriptor fails with Maven 3.1.0 : No implementation for org.sonatype.aether.RepositorySystem was bound (2013-07-16 - Bug - Robert Munteanu) https://issues.apache.org/jira/browse/KARAF-2395 [KARAF-2687] Better thread name for lock and shutdown background threads (2014-01-16 - Improvement - Claus Ibsen) https://issues.apache.org/jira/browse/KARAF-2687 [KARAF-2688] Karaf info - Add memory details about perm gen pool (2014-01-16 - Improvement - Claus Ibsen) https://issues.apache.org/jira/browse/KARAF-2688 [KARAF-2742] karaf-maven-plugin can not include filtered resources in a custom distribution (2014-01-29 - Bug - Partha Roy) https://issues.apache.org/jira/browse/KARAF-2742 [KARAF-2743] karaf-maven-plugin can not create custom Karaf with Apache Camel (2014-01-29 - Bug - Partha Roy) https://issues.apache.org/jira/browse/KARAF-2743 [KARAF-2744] Actualize the manual about writing tests to pax-exam-container-karaf (2014-01-29 - Documentation - Krzysztof Sobkowiak) https://issues.apache.org/jira/browse/KARAF-2744
