You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2012/03/06 11:03:45 UTC

Update on Karaf 3.0.0

Hi all,

I would like to make an update on the status of Karaf 3.0.

1/ Bootstrap time and artifacts resolution
I fixed the latest issue around pax-url-aether and artifacts resolution 
on Saturday.
Now, for SNAPSHOT artifacts, the karaf-maven-plugin (create-kar and 
install-kar goals) creates or copy the maven-metadata-local.xml.
It means that only new SNAPSHOTs will be downloaded from a remote 
repository.
More than easy testing/updating, a good news is that the artifact 
resolution is largely quicker than before, and so the Karaf bootstrap 
time is largely better (now the Karaf bootstrap on trunk is equivalent 
to Karaf 2.2.x).

2/ Sub-shell
As we discussed during the latest meeting, a new feature expected in 
Karaf 3.0.0 is sub-shell.
I started to work on it yesterday afternoon and I have something working:

karaf@root()> region
karaf@root(region)> exit
karaf@root()>

I have new enhancements to perform (multiple sub-shells support, 
completion contextual to a sub-shell, etc).
I will certainly commit a "work in progress" today and complete it 
tomorrow and the day after.

3/ Admin replaced by instance
As you probably saw, the admin module has been renamed to instance.
It includes the MBeans, and admin:* commands renamed to instance:*.

3/ Module refactoring
Christian provided a patch around config handling.
I will refactore it a bit to adopt the same way as feature, system, etc 
modules (core bundle, management bundle, command bundle).
I will take update some others modules in the same way.
It should be done tomorrow evening or Thursday mornning.

3/ Dependencies update and Aries features
I'm going to update some dependencies in Karaf 3.0 in order to be up to 
date.
We have currently an issue in Aries bundles/features. Depending of the 
Aries features, it requires aries-util 0.4 or aries-util 0.5. As the 
Aries bundles don't use version range, it means that it should be aligned.
I'm fixing this issue (and eventually raise some Jira/patches to Aries).

4/ Karaf 3.0.0 branch
I plan to cut off the karaf-3.0.x branch over the week end and prepare a 
first RC.

Regards
JB
-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Update on Karaf 3.0.0

Posted by Guillaume Nodet <gn...@gmail.com>.
On Tue, Mar 6, 2012 at 12:52, Christian Schneider
<ch...@die-schneider.net>wrote:

> Hi JB,
>
> Am 06.03.2012 11:03, schrieb Jean-Baptiste Onofré:
>
>  Hi all,
>>
>> I would like to make an update on the status of Karaf 3.0.
>>
>> 1/ Bootstrap time and artifacts resolution
>> I fixed the latest issue around pax-url-aether and artifacts resolution
>> on Saturday.
>> Now, for SNAPSHOT artifacts, the karaf-maven-plugin (create-kar and
>> install-kar goals) creates or copy the maven-metadata-local.xml.
>> It means that only new SNAPSHOTs will be downloaded from a remote
>> repository.
>> More than easy testing/updating, a good news is that the artifact
>> resolution is largely quicker than before, and so the Karaf bootstrap time
>> is largely better (now the Karaf bootstrap on trunk is equivalent to Karaf
>> 2.2.x).
>>
> I found more bugs / strange behaviour in the current version. The
> immediate problem I had is fixed. So my snapshot of the shell/config is
> used now after I do a full build.
> The problem is that I can not really update my jar in a running karaf.
> Update <bundleid> does not find my new version. dev:watch also does not
> work.
> When I delete the artifact´s dir in system and do update karaf loads the
> snapshot from the external repo.
>
> So I think the problem is that system is currently used somehat like an
> local repo. Karaf writes downloaded artifacts there. On the other hand is
> is used like a remote repo when
> looking up artifacts.
>
> I think this looks quite broken.
>
> I will add a jira issue.
>
>  3/ Module refactoring
>> Christian provided a patch around config handling.
>> I will refactore it a bit to adopt the same way as feature, system, etc
>> modules (core bundle, management bundle, command bundle).
>> I will take update some others modules in the same way.
>> It should be done tomorrow evening or Thursday mornning.
>>
> Please do not yet refactor this. Let me first commit on trunk. I am doing
> the last tests and will commit today. If you tell me what you want I can
> also do the refactoring.
> The patch I submitted was for 2.2.x. After a discussion with Achim we
> agreed that we should not change much for 2.2.x and instead just fix the
> bug with delayed updates.
> I will fix this on trunk first and then backport to 2.2.x.
>
>
>  4/ Karaf 3.0.0 branch
>> I plan to cut off the karaf-3.0.x branch over the week end and prepare a
>> first RC.
>>
>>  When I look in jira I see ~100 open issues for 3.0.0. So I think we are
> far from ready to branch and release a RC.


If we wait until all issues are closed, I fear we'll wait forever, as
issues are opened regularly.
We can just defer them to 3.1.


>
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>


-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Re: Update on Karaf 3.0.0

Posted by Christian Schneider <ch...@die-schneider.net>.
Am 06.03.2012 13:10, schrieb Jean-Baptiste Onofré:
>
> I'm really concerned about this feedback because:
> - we discussed about the Karaf 3.0 release in December, including a 
> review during the meeting in January. Now we have different point of 
> view that should have been discussed before
> - I'm feeling quite the only one really working on trunk, in 
> preparation for 3.0.0. Some of use spent times to fix issues (on 
> assemblies, on features, on Maven plugin, etc), started to implement 
> the features that we discussed during the meeting (sub-shell). No, 
> whereas we decided 2 months ago to cut off the branch, we don't have a 
> consensus ? The trunk version is really so bad ? I don't think so, but 
> maybe I'm wrong.
>
> JB, in a frustrated mode ;)

I did not intend to frustrate you. I just wanted to point out that we 
need to agree on the issues to go into 3.0. As long as there are so many 
open issues I think it is a true statement that we are not ready for a 
release.

Currently I am heavily involved in a customer project so I only have 
very limited time. Still I will help where I can. A real problem for me 
is the aether issue as I currently can not reliably test on trunk. So as 
soon as this is fixed
I can concentrate on helping to get trunk ready for 3.0.

Christian


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Re: Update on Karaf 3.0.0

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Christian,

my comments inline:

>> 1/ Bootstrap time and artifacts resolution
>> I fixed the latest issue around pax-url-aether and artifacts
>> resolution on Saturday.
>> Now, for SNAPSHOT artifacts, the karaf-maven-plugin (create-kar and
>> install-kar goals) creates or copy the maven-metadata-local.xml.
>> It means that only new SNAPSHOTs will be downloaded from a remote
>> repository.
>> More than easy testing/updating, a good news is that the artifact
>> resolution is largely quicker than before, and so the Karaf bootstrap
>> time is largely better (now the Karaf bootstrap on trunk is equivalent
>> to Karaf 2.2.x).
> I found more bugs / strange behaviour in the current version. The
> immediate problem I had is fixed. So my snapshot of the shell/config is
> used now after I do a full build.
> The problem is that I can not really update my jar in a running karaf.
> Update <bundleid> does not find my new version. dev:watch also does not
> work.
> When I delete the artifact´s dir in system and do update karaf loads the
> snapshot from the external repo.
>
> So I think the problem is that system is currently used somehat like an
> local repo. Karaf writes downloaded artifacts there. On the other hand
> is is used like a remote repo when
> looking up artifacts.
>
> I think this looks quite broken.

With pax-url-aether, the Karaf system folder is *really* considered like 
a Maven 3 repo.
Previously with pax-url-mvn, it was a kind of Maven 2 repo without using 
Maven API.
So the Karaf system folder exactly behaves as your .m2/repository repo.

It means that, in your m2 repo, if you copy a jar file, and the same are 
present on Central for instance, your jar will be overrided by the 
remote artifact.
That's why you type mvn install: mvn install goal generates the 
maven-metadata-local.xml for you to overwrite your jar only if a new one 
is present on Central.

So Karaf system folder works like this. The karaf-maven-plugin now 
generates the maven-metadata-local.xml. If you want to install only a 
jar in the system folder, you have to use:
mvn install:install-file -Dfile=... -Durl=file:/path/to/karaf/system

It's the expected behavior, matching the aether lifecycle.

>
> I will add a jira issue.
>> 3/ Module refactoring
>> Christian provided a patch around config handling.
>> I will refactore it a bit to adopt the same way as feature, system,
>> etc modules (core bundle, management bundle, command bundle).
>> I will take update some others modules in the same way.
>> It should be done tomorrow evening or Thursday mornning.
> Please do not yet refactor this. Let me first commit on trunk. I am
> doing the last tests and will commit today. If you tell me what you want
> I can also do the refactoring.
> The patch I submitted was for 2.2.x. After a discussion with Achim we
> agreed that we should not change much for 2.2.x and instead just fix the
> bug with delayed updates.
> I will fix this on trunk first and then backport to 2.2.x.

OK let me know when I can refactore.

>
>> 4/ Karaf 3.0.0 branch
>> I plan to cut off the karaf-3.0.x branch over the week end and prepare
>> a first RC.
>>
> When I look in jira I see ~100 open issues for 3.0.0. So I think we are
> far from ready to branch and release a RC.

I think that lot of Jira could be moved to 3.1.
I propose to review this Jira and get back to you with a clear roadmap 
for 3.0.

I'm really concerned about this feedback because:
- we discussed about the Karaf 3.0 release in December, including a 
review during the meeting in January. Now we have different point of 
view that should have been discussed before
- I'm feeling quite the only one really working on trunk, in preparation 
for 3.0.0. Some of use spent times to fix issues (on assemblies, on 
features, on Maven plugin, etc), started to implement the features that 
we discussed during the meeting (sub-shell). No, whereas we decided 2 
months ago to cut off the branch, we don't have a consensus ? The trunk 
version is really so bad ? I don't think so, but maybe I'm wrong.

JB, in a frustrated mode ;)
-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Update on Karaf 3.0.0

Posted by Christian Schneider <ch...@die-schneider.net>.
Moving the issues is fine for me. I just would like to delay the branch 
till we know that most remaining issues are bug fixes and not features. 
So I think top priority should
be to move all issues that can be moved.

Christian


Am 06.03.2012 13:12, schrieb Jamie G.:
> @Christian branching 3.0.x from trunk will allow us more flexibility
> to move towards a RC. We can push out issues to the 3.1.x line while
> polishing the 3.0.x line for RC.
>
> Cheers,
> Jamie
>
>

-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Re: Update on Karaf 3.0.0

Posted by "Jamie G." <ja...@gmail.com>.
@Christian branching 3.0.x from trunk will allow us more flexibility
to move towards a RC. We can push out issues to the 3.1.x line while
polishing the 3.0.x line for RC.

Cheers,
Jamie

On Tue, Mar 6, 2012 at 8:22 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
> Hi JB,
>
> Am 06.03.2012 11:03, schrieb Jean-Baptiste Onofré:
>
>> Hi all,
>>
>> I would like to make an update on the status of Karaf 3.0.
>>
>> 1/ Bootstrap time and artifacts resolution
>> I fixed the latest issue around pax-url-aether and artifacts resolution on
>> Saturday.
>> Now, for SNAPSHOT artifacts, the karaf-maven-plugin (create-kar and
>> install-kar goals) creates or copy the maven-metadata-local.xml.
>> It means that only new SNAPSHOTs will be downloaded from a remote
>> repository.
>> More than easy testing/updating, a good news is that the artifact
>> resolution is largely quicker than before, and so the Karaf bootstrap time
>> is largely better (now the Karaf bootstrap on trunk is equivalent to Karaf
>> 2.2.x).
>
> I found more bugs / strange behaviour in the current version. The immediate
> problem I had is fixed. So my snapshot of the shell/config is used now after
> I do a full build.
> The problem is that I can not really update my jar in a running karaf.
> Update <bundleid> does not find my new version. dev:watch also does not
> work.
> When I delete the artifact´s dir in system and do update karaf loads the
> snapshot from the external repo.
>
> So I think the problem is that system is currently used somehat like an
> local repo. Karaf writes downloaded artifacts there. On the other hand is is
> used like a remote repo when
> looking up artifacts.
>
> I think this looks quite broken.
>
> I will add a jira issue.
>
>> 3/ Module refactoring
>> Christian provided a patch around config handling.
>> I will refactore it a bit to adopt the same way as feature, system, etc
>> modules (core bundle, management bundle, command bundle).
>> I will take update some others modules in the same way.
>> It should be done tomorrow evening or Thursday mornning.
>
> Please do not yet refactor this. Let me first commit on trunk. I am doing
> the last tests and will commit today. If you tell me what you want I can
> also do the refactoring.
> The patch I submitted was for 2.2.x. After a discussion with Achim we agreed
> that we should not change much for 2.2.x and instead just fix the bug with
> delayed updates.
> I will fix this on trunk first and then backport to 2.2.x.
>
>
>> 4/ Karaf 3.0.0 branch
>> I plan to cut off the karaf-3.0.x branch over the week end and prepare a
>> first RC.
>>
> When I look in jira I see ~100 open issues for 3.0.0. So I think we are far
> from ready to branch and release a RC.
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>

Re: Update on Karaf 3.0.0

Posted by Christian Schneider <ch...@die-schneider.net>.
Hi JB,

Am 06.03.2012 11:03, schrieb Jean-Baptiste Onofré:
> Hi all,
>
> I would like to make an update on the status of Karaf 3.0.
>
> 1/ Bootstrap time and artifacts resolution
> I fixed the latest issue around pax-url-aether and artifacts 
> resolution on Saturday.
> Now, for SNAPSHOT artifacts, the karaf-maven-plugin (create-kar and 
> install-kar goals) creates or copy the maven-metadata-local.xml.
> It means that only new SNAPSHOTs will be downloaded from a remote 
> repository.
> More than easy testing/updating, a good news is that the artifact 
> resolution is largely quicker than before, and so the Karaf bootstrap 
> time is largely better (now the Karaf bootstrap on trunk is equivalent 
> to Karaf 2.2.x).
I found more bugs / strange behaviour in the current version. The 
immediate problem I had is fixed. So my snapshot of the shell/config is 
used now after I do a full build.
The problem is that I can not really update my jar in a running karaf. 
Update <bundleid> does not find my new version. dev:watch also does not 
work.
When I delete the artifact´s dir in system and do update karaf loads the 
snapshot from the external repo.

So I think the problem is that system is currently used somehat like an 
local repo. Karaf writes downloaded artifacts there. On the other hand 
is is used like a remote repo when
looking up artifacts.

I think this looks quite broken.

I will add a jira issue.
> 3/ Module refactoring
> Christian provided a patch around config handling.
> I will refactore it a bit to adopt the same way as feature, system, 
> etc modules (core bundle, management bundle, command bundle).
> I will take update some others modules in the same way.
> It should be done tomorrow evening or Thursday mornning.
Please do not yet refactor this. Let me first commit on trunk. I am 
doing the last tests and will commit today. If you tell me what you want 
I can also do the refactoring.
The patch I submitted was for 2.2.x. After a discussion with Achim we 
agreed that we should not change much for 2.2.x and instead just fix the 
bug with delayed updates.
I will fix this on trunk first and then backport to 2.2.x.

> 4/ Karaf 3.0.0 branch
> I plan to cut off the karaf-3.0.x branch over the week end and prepare 
> a first RC.
>
When I look in jira I see ~100 open issues for 3.0.0. So I think we are 
far from ready to branch and release a RC.

Christian

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Re: Update on Karaf 3.0.0

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Sure ;)

On 03/06/2012 12:07 PM, Ioannis Canellos wrote:
> Great news!
>
> I'd like to make a really trivial aesthetic comment. Could the sub
> shell prompt have no parenthesis when no sub shell is active:
>
> karaf@root>  region
> karaf@root(region)>  exit
> karaf@root>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Update on Karaf 3.0.0

Posted by Ioannis Canellos <io...@gmail.com>.
Great news!

I'd like to make a really trivial aesthetic comment. Could the sub
shell prompt have no parenthesis when no sub shell is active:

karaf@root> region
karaf@root(region)> exit
karaf@root>

-- 
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>

**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*