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 2014/02/25 10:57:28 UTC
[PROPOSAL] Roadmap
Hi all,
In the latest weeks, we discussed about different topics and changes for
Karaf. We had very interesting different proposals, discussions, etc.
However, some discussions were on IRC, so it's not easy for everybody to
follow.
I would like to summarise the different topics and build a roadmap.
I gonna update the roadmap wiki page:
https://cwiki.apache.org/confluence/display/KARAF/Roadmap
But before updating the wiki page, I would like to share with you all
the different topics and provide a global picture overview.
1/ Short term (3.0.x/3.1.x)
-------------
- Fixed and enhancements on the maven-karaf-plugin. It's on my TODO for
today. It includes several fixes, add more tests, and support of Maven
3.1/3.2
- Usage of commons-daemon. As we are stuck to a old Tanuki JSW wrapper
(license issue), I prepared the usage of Apache commons-daemon on a
branch. I will push this branch to let you take a look.
- Samples and developer guide. I prepared a branch where I replaced the
demos modules with samples modules. The purpose is to illustrate the
developer guide (that I refactored/enhanced too) with CDI, JPA, etc samples.
- Net/minimal distributions. In addition of the "standard" distribution,
we will provide two other distributions: the net is very very minimal
and will download all artifacts from remote repository (Internet) at
startup, on the other hand, minimal distribution contains a minimal
system repository and allow to easily construct custom distribution.
- Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
bundles: in Karaf itself, or due to dependency projects (like Pax URL
for instance). If I think it's good, maybe we want a bit far and, if
possible, I would reduce the number of bundles started.
- Own versioning for Spring and Enteprise Karaf Features: now, to
upgrade to new version of Spring, Hibernate, OpenJPA, etc, we have to
release a new version of Karaf. Of course, the Karaf features should be
provided by the projects themselves, but waiting this, I would like to
manage Spring and Enterprise Karaf features as "standalone". The
codebase stays where it's, but instead of depending to Karaf parent POM,
it will depend directly to Apache POM and excluded from the Karaf reactor.
2/ Middle term (3.1.x/future)
--------------
- Blueprint dependency and more usage of pure OSGi/DS. Now, lot of Karaf
modules depend to blueprint (for IoC or namespace handler). In order to
minimise the footprint, and avoid some issues (like proxy), it would be
great to set Blueprint as optional and more use pure OSGi or DS
internally in Karaf. We should also provide a better "advertising" about
DS support.
- Generic shell commands. Now, projects (like CXF, Camel, etc) depends
to Karaf shell modules (and console by transitivity). The purpose is:
1/ simplify the usage/coding of commands (providing annotation especially)
2/ avoid the dependency to blueprint (especially the namespace handler)
3/ reduce the dependency
4/ provide a better support of Felix Gogo shell in Karaf
Again, the purpose of this e-mail is not to details each section, but to
provide a global picture. The details will go into the corresponding Jira.
Thoughts ?
Regards
JB
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Roadmap
Posted by Filippo Balicchia <fb...@gmail.com>.
Thanks All for sharing these info,
it gave me a global picture that without that I struggled to find.
--Filippo
2014-02-25 14:53 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
> On 25.02.2014 14:44, Guillaume Nodet wrote:
>
>> 2014-02-25 13:49 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>>
>> Hi Guillaume,
>>>
>>> some questions and comments inline.
>>>
>>>
>>> On 25.02.2014 11:14, Guillaume Nodet wrote:
>>>
>>> demos modules with samples modules. The purpose is to illustrate the
>>>> developer guide (that I refactored/enhanced too) with CDI, JPA, etc
>>>> samples.
>>>> - Net/minimal distributions. In addition of the "standard" distribution,
>>>> we will provide two other distributions: the net is very very minimal
>>>> and
>>>> will download all artifacts from remote repository (Internet) at
>>>> startup,
>>>> on the other hand, minimal distribution contains a minimal system
>>>> repository and allow to easily construct custom distribution.
>>>> - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
>>>> bundles: in Karaf itself, or due to dependency projects (like Pax URL
>>>> for
>>>> instance). If I think it's good, maybe we want a bit far and, if
>>>> possible,
>>>> I would reduce the number of bundles started.
>>>>
>>>> I'm currently working on pax-url to provide uber-bundles which we'll be
>>>> able to integrate instead of dragging a dozen of bundles.
>>>> I'm also re-integrating gogo into shell/console (the split I did back in
>>>> december was not actually really good and kept lots of duplicated
>>>> packages).
>>>> And also jansi which is already provided by the jline bundle.
>>>> With those 3 modifications, i'm currently down to 37 bundles ...
>>>>
>>>> Can you provide some details about the uber bundles? Which of these
>>> bundles would we have an what would they contain?
>>>
>>> The goal is simply to have pax-url-aether, pax-url-wrap and pax-url-war
>> being standalone bundles.
>> That was the case before 1.4.0 and I aim to provide 2 bundles for those so
>> that people can choose to use smaller ones or standalone ones.
>>
> +1
>
> Though even better would be to make pax url simpler so there are less
> deps. But for a short term solution these bundles would help a lot.
>
>
>
>> About shell console. As far as I can see gogo is already integrated
>>> inside
>>> shell.console. I think we embed the packages.
>>> Regarding jline I would like to keep jline separate as it has native code
>>> in it which made packaging of shell console a bit more challenging.
>>> I am pretty happy about the current granularity of shell.console.Having
>>> jline separate also shields us from internal packaging details of jline
>>> which
>>> might change between versions.
>>>
>>
>> What I meant is that gogo-runtime and jansi are installed as bundles but
>> those are duplicate packages because they are already provided
>> respectively
>> by shell.console and jline. The only real thing to do is to remove them
>> from the framework kar (and reference the activator in shell/console).
>>
> +1 Makes a lot of sense. I guess they were just forgotten.
>
>
>> For jline, i'm not sure. In 2.x is was inlined in shell.console and it
>> has
>> been split apart in 3.x. Ideally, it would be hidden and embedded as
>> that's a console implementation detail and should not be leaked outside.
>> Unfortunately, we have a few dependencies on it, so I'm not sure we can
>> actually hide it, in which case, I'd keep the current packaging. The main
>> bundle which would cause problems if we were to inline and hide jline
>> would
>> be jledit which has strong ties to jline. I think the other uses we have
>> could be mostly refactored, but in all cases, having a cleaner api for the
>> console would be good, it could just be a wrapper around jline Terminal,
>> which is the main (and only ?) class actually used (outside the console).
>>
> I think we can not really hide it. Karaf ssh and the gogo webconsole
> plugin also use jline (At least Terminal).
> So I think the separate bundle is the least effort for us.
>
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: [PROPOSAL] Roadmap
Posted by Christian Schneider <ch...@die-schneider.net>.
On 25.02.2014 14:44, Guillaume Nodet wrote:
> 2014-02-25 13:49 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>
>> Hi Guillaume,
>>
>> some questions and comments inline.
>>
>>
>> On 25.02.2014 11:14, Guillaume Nodet wrote:
>>
>>> demos modules with samples modules. The purpose is to illustrate the
>>> developer guide (that I refactored/enhanced too) with CDI, JPA, etc
>>> samples.
>>> - Net/minimal distributions. In addition of the "standard" distribution,
>>> we will provide two other distributions: the net is very very minimal and
>>> will download all artifacts from remote repository (Internet) at startup,
>>> on the other hand, minimal distribution contains a minimal system
>>> repository and allow to easily construct custom distribution.
>>> - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
>>> bundles: in Karaf itself, or due to dependency projects (like Pax URL for
>>> instance). If I think it's good, maybe we want a bit far and, if possible,
>>> I would reduce the number of bundles started.
>>>
>>> I'm currently working on pax-url to provide uber-bundles which we'll be
>>> able to integrate instead of dragging a dozen of bundles.
>>> I'm also re-integrating gogo into shell/console (the split I did back in
>>> december was not actually really good and kept lots of duplicated
>>> packages).
>>> And also jansi which is already provided by the jline bundle.
>>> With those 3 modifications, i'm currently down to 37 bundles ...
>>>
>> Can you provide some details about the uber bundles? Which of these
>> bundles would we have an what would they contain?
>>
> The goal is simply to have pax-url-aether, pax-url-wrap and pax-url-war
> being standalone bundles.
> That was the case before 1.4.0 and I aim to provide 2 bundles for those so
> that people can choose to use smaller ones or standalone ones.
+1
Though even better would be to make pax url simpler so there are less
deps. But for a short term solution these bundles would help a lot.
>
>> About shell console. As far as I can see gogo is already integrated inside
>> shell.console. I think we embed the packages.
>> Regarding jline I would like to keep jline separate as it has native code
>> in it which made packaging of shell console a bit more challenging.
>> I am pretty happy about the current granularity of shell.console.Having
>> jline separate also shields us from internal packaging details of jline
>> which
>> might change between versions.
>
> What I meant is that gogo-runtime and jansi are installed as bundles but
> those are duplicate packages because they are already provided respectively
> by shell.console and jline. The only real thing to do is to remove them
> from the framework kar (and reference the activator in shell/console).
+1 Makes a lot of sense. I guess they were just forgotten.
>
> For jline, i'm not sure. In 2.x is was inlined in shell.console and it has
> been split apart in 3.x. Ideally, it would be hidden and embedded as
> that's a console implementation detail and should not be leaked outside.
> Unfortunately, we have a few dependencies on it, so I'm not sure we can
> actually hide it, in which case, I'd keep the current packaging. The main
> bundle which would cause problems if we were to inline and hide jline would
> be jledit which has strong ties to jline. I think the other uses we have
> could be mostly refactored, but in all cases, having a cleaner api for the
> console would be good, it could just be a wrapper around jline Terminal,
> which is the main (and only ?) class actually used (outside the console).
I think we can not really hide it. Karaf ssh and the gogo webconsole
plugin also use jline (At least Terminal).
So I think the separate bundle is the least effort for us.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [PROPOSAL] Roadmap
Posted by Guillaume Nodet <gn...@apache.org>.
2014-02-25 13:49 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
> Hi Guillaume,
>
> some questions and comments inline.
>
>
> On 25.02.2014 11:14, Guillaume Nodet wrote:
>
>> demos modules with samples modules. The purpose is to illustrate the
>> developer guide (that I refactored/enhanced too) with CDI, JPA, etc
>> samples.
>> - Net/minimal distributions. In addition of the "standard" distribution,
>> we will provide two other distributions: the net is very very minimal and
>> will download all artifacts from remote repository (Internet) at startup,
>> on the other hand, minimal distribution contains a minimal system
>> repository and allow to easily construct custom distribution.
>> - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
>> bundles: in Karaf itself, or due to dependency projects (like Pax URL for
>> instance). If I think it's good, maybe we want a bit far and, if possible,
>> I would reduce the number of bundles started.
>>
>> I'm currently working on pax-url to provide uber-bundles which we'll be
>> able to integrate instead of dragging a dozen of bundles.
>> I'm also re-integrating gogo into shell/console (the split I did back in
>> december was not actually really good and kept lots of duplicated
>> packages).
>> And also jansi which is already provided by the jline bundle.
>> With those 3 modifications, i'm currently down to 37 bundles ...
>>
> Can you provide some details about the uber bundles? Which of these
> bundles would we have an what would they contain?
>
The goal is simply to have pax-url-aether, pax-url-wrap and pax-url-war
being standalone bundles.
That was the case before 1.4.0 and I aim to provide 2 bundles for those so
that people can choose to use smaller ones or standalone ones.
> About shell console. As far as I can see gogo is already integrated inside
> shell.console. I think we embed the packages.
> Regarding jline I would like to keep jline separate as it has native code
> in it which made packaging of shell console a bit more challenging.
> I am pretty happy about the current granularity of shell.console.Having
> jline separate also shields us from internal packaging details of jline
> which
> might change between versions.
What I meant is that gogo-runtime and jansi are installed as bundles but
those are duplicate packages because they are already provided respectively
by shell.console and jline. The only real thing to do is to remove them
from the framework kar (and reference the activator in shell/console).
For jline, i'm not sure. In 2.x is was inlined in shell.console and it has
been split apart in 3.x. Ideally, it would be hidden and embedded as
that's a console implementation detail and should not be leaked outside.
Unfortunately, we have a few dependencies on it, so I'm not sure we can
actually hide it, in which case, I'd keep the current packaging. The main
bundle which would cause problems if we were to inline and hide jline would
be jledit which has strong ties to jline. I think the other uses we have
could be mostly refactored, but in all cases, having a cleaner api for the
console would be good, it could just be a wrapper around jline Terminal,
which is the main (and only ?) class actually used (outside the console).
>
> 2/ Middle term (3.1.x/future)
>>> --------------
>>> - Blueprint dependency and more usage of pure OSGi/DS. Now, lot of Karaf
>>> modules depend to blueprint (for IoC or namespace handler). In order to
>>> minimise the footprint, and avoid some issues (like proxy), it would be
>>> great to set Blueprint as optional and more use pure OSGi or DS
>>> internally
>>> in Karaf. We should also provide a better "advertising" about DS support.
>>>
>>> I have a branch which works without blueprint at all. I don't really
>> want
>> to push it now to asf because I'm rebasing from time to time on master,
>> and
>> I don't think the asf allows forced push. But if that's the case, I'd be
>> happy to push it so that people can have a look.
>> It's not entirely finished as we'd have to take care about the features
>> definition and distribution.
>>
> Great to hear you are as far already. I think it would be great to have a
> look on this.
> From my point of view I would like to see the DS migration rather earlier
> than later.
> As it is just an internal change I think technically we could deliver it
> in any 3.x (minor) release.
> I know this is currently planned for 4.0 but perhaps we can rethink this
> if the DS version of karaf is stable and compatible.
>
> Best regards
>
> Christian
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: [PROPOSAL] Roadmap
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi guys,
some comments:
1/ I will take a look on Guillaume's changes about Pax URL. I think it's
good to embed some part. For instance, pax-url-wrap required to install
bndTool, swissbox, tinybundle, etc (AFAIR): we can just embed the
necessary in the Pax URL bundles.
2/ Yes and no for gogo.shell. AFAIR, we "duplicated" the gogo shell code
(at a previous point). We provide directly org.apache.felix.gogo*
packages (but it doesn't come from the gogo artifact).
Agree for jline.
3/ I agree with Christian about DS, but not necessary for commands. As I
proposed in the previous e-mail, leveraging more pure OSGi and DS is
something that we can start. I started to refactore some modules on a
local branch to avoid usage of blueprint (based on master).
Regards
JB
On 02/25/2014 01:49 PM, Christian Schneider wrote:
> Hi Guillaume,
>
> some questions and comments inline.
>
> On 25.02.2014 11:14, Guillaume Nodet wrote:
>> demos modules with samples modules. The purpose is to illustrate the
>> developer guide (that I refactored/enhanced too) with CDI, JPA, etc
>> samples.
>> - Net/minimal distributions. In addition of the "standard" distribution,
>> we will provide two other distributions: the net is very very minimal and
>> will download all artifacts from remote repository (Internet) at startup,
>> on the other hand, minimal distribution contains a minimal system
>> repository and allow to easily construct custom distribution.
>> - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
>> bundles: in Karaf itself, or due to dependency projects (like Pax URL for
>> instance). If I think it's good, maybe we want a bit far and, if
>> possible,
>> I would reduce the number of bundles started.
>>
>> I'm currently working on pax-url to provide uber-bundles which we'll be
>> able to integrate instead of dragging a dozen of bundles.
>> I'm also re-integrating gogo into shell/console (the split I did back in
>> december was not actually really good and kept lots of duplicated
>> packages).
>> And also jansi which is already provided by the jline bundle.
>> With those 3 modifications, i'm currently down to 37 bundles ...
> Can you provide some details about the uber bundles? Which of these
> bundles would we have an what would they contain?
>
> About shell console. As far as I can see gogo is already integrated
> inside shell.console. I think we embed the packages.
> Regarding jline I would like to keep jline separate as it has native
> code in it which made packaging of shell console a bit more challenging.
> I am pretty happy about the current granularity of shell.console.Having
> jline separate also shields us from internal packaging details of jline
> which
> might change between versions.
>>> 2/ Middle term (3.1.x/future)
>>> --------------
>>> - Blueprint dependency and more usage of pure OSGi/DS. Now, lot of Karaf
>>> modules depend to blueprint (for IoC or namespace handler). In order to
>>> minimise the footprint, and avoid some issues (like proxy), it would be
>>> great to set Blueprint as optional and more use pure OSGi or DS
>>> internally
>>> in Karaf. We should also provide a better "advertising" about DS
>>> support.
>>>
>> I have a branch which works without blueprint at all. I don't really
>> want
>> to push it now to asf because I'm rebasing from time to time on
>> master, and
>> I don't think the asf allows forced push. But if that's the case, I'd be
>> happy to push it so that people can have a look.
>> It's not entirely finished as we'd have to take care about the features
>> definition and distribution.
> Great to hear you are as far already. I think it would be great to have
> a look on this.
> From my point of view I would like to see the DS migration rather
> earlier than later.
> As it is just an internal change I think technically we could deliver it
> in any 3.x (minor) release.
> I know this is currently planned for 4.0 but perhaps we can rethink this
> if the DS version of karaf is stable and compatible.
>
> Best regards
>
> Christian
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Roadmap
Posted by Christian Schneider <ch...@die-schneider.net>.
Hi Guillaume,
some questions and comments inline.
On 25.02.2014 11:14, Guillaume Nodet wrote:
> demos modules with samples modules. The purpose is to illustrate the
> developer guide (that I refactored/enhanced too) with CDI, JPA, etc samples.
> - Net/minimal distributions. In addition of the "standard" distribution,
> we will provide two other distributions: the net is very very minimal and
> will download all artifacts from remote repository (Internet) at startup,
> on the other hand, minimal distribution contains a minimal system
> repository and allow to easily construct custom distribution.
> - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
> bundles: in Karaf itself, or due to dependency projects (like Pax URL for
> instance). If I think it's good, maybe we want a bit far and, if possible,
> I would reduce the number of bundles started.
>
> I'm currently working on pax-url to provide uber-bundles which we'll be
> able to integrate instead of dragging a dozen of bundles.
> I'm also re-integrating gogo into shell/console (the split I did back in
> december was not actually really good and kept lots of duplicated packages).
> And also jansi which is already provided by the jline bundle.
> With those 3 modifications, i'm currently down to 37 bundles ...
Can you provide some details about the uber bundles? Which of these
bundles would we have an what would they contain?
About shell console. As far as I can see gogo is already integrated
inside shell.console. I think we embed the packages.
Regarding jline I would like to keep jline separate as it has native
code in it which made packaging of shell console a bit more challenging.
I am pretty happy about the current granularity of shell.console.Having
jline separate also shields us from internal packaging details of jline
which
might change between versions.
>> 2/ Middle term (3.1.x/future)
>> --------------
>> - Blueprint dependency and more usage of pure OSGi/DS. Now, lot of Karaf
>> modules depend to blueprint (for IoC or namespace handler). In order to
>> minimise the footprint, and avoid some issues (like proxy), it would be
>> great to set Blueprint as optional and more use pure OSGi or DS internally
>> in Karaf. We should also provide a better "advertising" about DS support.
>>
> I have a branch which works without blueprint at all. I don't really want
> to push it now to asf because I'm rebasing from time to time on master, and
> I don't think the asf allows forced push. But if that's the case, I'd be
> happy to push it so that people can have a look.
> It's not entirely finished as we'd have to take care about the features
> definition and distribution.
Great to hear you are as far already. I think it would be great to have
a look on this.
From my point of view I would like to see the DS migration rather
earlier than later.
As it is just an internal change I think technically we could deliver it
in any 3.x (minor) release.
I know this is currently planned for 4.0 but perhaps we can rethink this
if the DS version of karaf is stable and compatible.
Best regards
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: [PROPOSAL] Roadmap
Posted by Guillaume Nodet <gn...@apache.org>.
Just a few comments to explain what I've (am) working on...
2014-02-25 10:57 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Hi all,
>
> In the latest weeks, we discussed about different topics and changes for
> Karaf. We had very interesting different proposals, discussions, etc.
> However, some discussions were on IRC, so it's not easy for everybody to
> follow.
>
> I would like to summarise the different topics and build a roadmap.
>
> I gonna update the roadmap wiki page:
> https://cwiki.apache.org/confluence/display/KARAF/Roadmap
>
> But before updating the wiki page, I would like to share with you all the
> different topics and provide a global picture overview.
>
Thx a lot !
>
> 1/ Short term (3.0.x/3.1.x)
> -------------
> - Fixed and enhancements on the maven-karaf-plugin. It's on my TODO for
> today. It includes several fixes, add more tests, and support of Maven
> 3.1/3.2
> - Usage of commons-daemon. As we are stuck to a old Tanuki JSW wrapper
> (license issue), I prepared the usage of Apache commons-daemon on a branch.
> I will push this branch to let you take a look.
>
Is commons-daemon now on par with wrapper ? i must admit i haven't looked
in a few years ....
- Samples and developer guide. I prepared a branch where I replaced the
> demos modules with samples modules. The purpose is to illustrate the
> developer guide (that I refactored/enhanced too) with CDI, JPA, etc samples.
> - Net/minimal distributions. In addition of the "standard" distribution,
> we will provide two other distributions: the net is very very minimal and
> will download all artifacts from remote repository (Internet) at startup,
> on the other hand, minimal distribution contains a minimal system
> repository and allow to easily construct custom distribution.
> - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
> bundles: in Karaf itself, or due to dependency projects (like Pax URL for
> instance). If I think it's good, maybe we want a bit far and, if possible,
> I would reduce the number of bundles started.
>
I'm currently working on pax-url to provide uber-bundles which we'll be
able to integrate instead of dragging a dozen of bundles.
I'm also re-integrating gogo into shell/console (the split I did back in
december was not actually really good and kept lots of duplicated packages).
And also jansi which is already provided by the jline bundle.
With those 3 modifications, i'm currently down to 37 bundles ...
> - Own versioning for Spring and Enteprise Karaf Features: now, to upgrade
> to new version of Spring, Hibernate, OpenJPA, etc, we have to release a new
> version of Karaf. Of course, the Karaf features should be provided by the
> projects themselves, but waiting this, I would like to manage Spring and
> Enterprise Karaf features as "standalone". The codebase stays where it's,
> but instead of depending to Karaf parent POM, it will depend directly to
> Apache POM and excluded from the Karaf reactor.
>
I'm a bit skeptical on that. We actually do release Karaf quite often, so
i'm not sure it will actually bring much...
>
> 2/ Middle term (3.1.x/future)
> --------------
> - Blueprint dependency and more usage of pure OSGi/DS. Now, lot of Karaf
> modules depend to blueprint (for IoC or namespace handler). In order to
> minimise the footprint, and avoid some issues (like proxy), it would be
> great to set Blueprint as optional and more use pure OSGi or DS internally
> in Karaf. We should also provide a better "advertising" about DS support.
>
I have a branch which works without blueprint at all. I don't really want
to push it now to asf because I'm rebasing from time to time on master, and
I don't think the asf allows forced push. But if that's the case, I'd be
happy to push it so that people can have a look.
It's not entirely finished as we'd have to take care about the features
definition and distribution.
> - Generic shell commands. Now, projects (like CXF, Camel, etc) depends to
> Karaf shell modules (and console by transitivity). The purpose is:
> 1/ simplify the usage/coding of commands (providing annotation especially)
> 2/ avoid the dependency to blueprint (especially the namespace handler)
> 3/ reduce the dependency
> 4/ provide a better support of Felix Gogo shell in Karaf
>
This is something Christian and I are working on. Master already contains
support for SCR based commands, and the blueprint namespace has been
enhanced to mostly get rid of all the declaration. Most of the command
definitions now look very simple:
https://github.com/apache/karaf/blob/master/config/command/src/main/resources/OSGI-INF/blueprint/shell-config.xml
Also, the SCR support is not completely finished as we're still missing
subshell when using SCR powered commands.
>
> Again, the purpose of this e-mail is not to details each section, but to
> provide a global picture. The details will go into the corresponding Jira.
>
> Thoughts ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [PROPOSAL] Roadmap
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Krzysztof
For 3.0.1.
Regards
JB
On 03/06/2014 08:08 PM, Krzysztof Sobkowiak wrote:
> Hi Jean-Baptiste
>
> When do you plan to push the changes for samples and developer guide?
>
> Regards
> Krzysztof
>
> On 25.02.2014 10:57, Jean-Baptiste Onofré wrote:
>> Hi all,
>>
>> In the latest weeks, we discussed about different topics and changes
>> for Karaf. We had very interesting different proposals, discussions,
>> etc. However, some discussions were on IRC, so it's not easy for
>> everybody to follow.
>>
>> I would like to summarise the different topics and build a roadmap.
>>
>> I gonna update the roadmap wiki page:
>> https://cwiki.apache.org/confluence/display/KARAF/Roadmap
>>
>> But before updating the wiki page, I would like to share with you all
>> the different topics and provide a global picture overview.
>>
>> 1/ Short term (3.0.x/3.1.x)
>> -------------
>> - Fixed and enhancements on the maven-karaf-plugin. It's on my TODO
>> for today. It includes several fixes, add more tests, and support of
>> Maven 3.1/3.2
>> - Usage of commons-daemon. As we are stuck to a old Tanuki JSW wrapper
>> (license issue), I prepared the usage of Apache commons-daemon on a
>> branch. I will push this branch to let you take a look.
>> - Samples and developer guide. I prepared a branch where I replaced
>> the demos modules with samples modules. The purpose is to illustrate
>> the developer guide (that I refactored/enhanced too) with CDI, JPA,
>> etc samples.
>> - Net/minimal distributions. In addition of the "standard"
>> distribution, we will provide two other distributions: the net is very
>> very minimal and will download all artifacts from remote repository
>> (Internet) at startup, on the other hand, minimal distribution
>> contains a minimal system repository and allow to easily construct
>> custom distribution.
>> - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
>> bundles: in Karaf itself, or due to dependency projects (like Pax URL
>> for instance). If I think it's good, maybe we want a bit far and, if
>> possible, I would reduce the number of bundles started.
>> - Own versioning for Spring and Enteprise Karaf Features: now, to
>> upgrade to new version of Spring, Hibernate, OpenJPA, etc, we have to
>> release a new version of Karaf. Of course, the Karaf features should
>> be provided by the projects themselves, but waiting this, I would like
>> to manage Spring and Enterprise Karaf features as "standalone". The
>> codebase stays where it's, but instead of depending to Karaf parent
>> POM, it will depend directly to Apache POM and excluded from the Karaf
>> reactor.
>>
>> 2/ Middle term (3.1.x/future)
>> --------------
>> - Blueprint dependency and more usage of pure OSGi/DS. Now, lot of
>> Karaf modules depend to blueprint (for IoC or namespace handler). In
>> order to minimise the footprint, and avoid some issues (like proxy),
>> it would be great to set Blueprint as optional and more use pure OSGi
>> or DS internally in Karaf. We should also provide a better
>> "advertising" about DS support.
>> - Generic shell commands. Now, projects (like CXF, Camel, etc) depends
>> to Karaf shell modules (and console by transitivity). The purpose is:
>> 1/ simplify the usage/coding of commands (providing annotation
>> especially)
>> 2/ avoid the dependency to blueprint (especially the namespace handler)
>> 3/ reduce the dependency
>> 4/ provide a better support of Felix Gogo shell in Karaf
>>
>> Again, the purpose of this e-mail is not to details each section, but
>> to provide a global picture. The details will go into the
>> corresponding Jira.
>>
>> Thoughts ?
>>
>> Regards
>> JB
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Roadmap
Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
Hi Jean-Baptiste
When do you plan to push the changes for samples and developer guide?
Regards
Krzysztof
On 25.02.2014 10:57, Jean-Baptiste Onofré wrote:
> Hi all,
>
> In the latest weeks, we discussed about different topics and changes
> for Karaf. We had very interesting different proposals, discussions,
> etc. However, some discussions were on IRC, so it's not easy for
> everybody to follow.
>
> I would like to summarise the different topics and build a roadmap.
>
> I gonna update the roadmap wiki page:
> https://cwiki.apache.org/confluence/display/KARAF/Roadmap
>
> But before updating the wiki page, I would like to share with you all
> the different topics and provide a global picture overview.
>
> 1/ Short term (3.0.x/3.1.x)
> -------------
> - Fixed and enhancements on the maven-karaf-plugin. It's on my TODO
> for today. It includes several fixes, add more tests, and support of
> Maven 3.1/3.2
> - Usage of commons-daemon. As we are stuck to a old Tanuki JSW wrapper
> (license issue), I prepared the usage of Apache commons-daemon on a
> branch. I will push this branch to let you take a look.
> - Samples and developer guide. I prepared a branch where I replaced
> the demos modules with samples modules. The purpose is to illustrate
> the developer guide (that I refactored/enhanced too) with CDI, JPA,
> etc samples.
> - Net/minimal distributions. In addition of the "standard"
> distribution, we will provide two other distributions: the net is very
> very minimal and will download all artifacts from remote repository
> (Internet) at startup, on the other hand, minimal distribution
> contains a minimal system repository and allow to easily construct
> custom distribution.
> - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
> bundles: in Karaf itself, or due to dependency projects (like Pax URL
> for instance). If I think it's good, maybe we want a bit far and, if
> possible, I would reduce the number of bundles started.
> - Own versioning for Spring and Enteprise Karaf Features: now, to
> upgrade to new version of Spring, Hibernate, OpenJPA, etc, we have to
> release a new version of Karaf. Of course, the Karaf features should
> be provided by the projects themselves, but waiting this, I would like
> to manage Spring and Enterprise Karaf features as "standalone". The
> codebase stays where it's, but instead of depending to Karaf parent
> POM, it will depend directly to Apache POM and excluded from the Karaf
> reactor.
>
> 2/ Middle term (3.1.x/future)
> --------------
> - Blueprint dependency and more usage of pure OSGi/DS. Now, lot of
> Karaf modules depend to blueprint (for IoC or namespace handler). In
> order to minimise the footprint, and avoid some issues (like proxy),
> it would be great to set Blueprint as optional and more use pure OSGi
> or DS internally in Karaf. We should also provide a better
> "advertising" about DS support.
> - Generic shell commands. Now, projects (like CXF, Camel, etc) depends
> to Karaf shell modules (and console by transitivity). The purpose is:
> 1/ simplify the usage/coding of commands (providing annotation
> especially)
> 2/ avoid the dependency to blueprint (especially the namespace handler)
> 3/ reduce the dependency
> 4/ provide a better support of Felix Gogo shell in Karaf
>
> Again, the purpose of this e-mail is not to details each section, but
> to provide a global picture. The details will go into the
> corresponding Jira.
>
> Thoughts ?
>
> Regards
> JB
--
Krzysztof Sobkowiak
JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Re: [PROPOSAL] Roadmap
Posted by Guillaume Nodet <gn...@apache.org>.
In addition, I'll soon start 2 discussion threads about 2 new features i'd
like to introduce:
- a new resolver on way to install features / bundles using the osgi
resolver the goal would be to have on a more "global" resolution when
installing features, i.e. compute the needed bundles to resolve all the
installed features, but still taking into account manually installed
bundles. I.e. when you install a new feature, the resolver would take the
features list and manually installed bundles and compute the full list of
bundles to be installed. This would also allow a much better feature
update mechanism.
- a patch mechanism which would complement the above model but more
specifically targeted at providing bug fixes i.e. not a completely new
feature version, but a way to distribute micro updates of bundles (I
already touched this area by introducing "overrides" in the feature
installation, but we're missing the whole picture).
Stay tuned !
2014-02-25 10:57 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Hi all,
>
> In the latest weeks, we discussed about different topics and changes for
> Karaf. We had very interesting different proposals, discussions, etc.
> However, some discussions were on IRC, so it's not easy for everybody to
> follow.
>
> I would like to summarise the different topics and build a roadmap.
>
> I gonna update the roadmap wiki page:
> https://cwiki.apache.org/confluence/display/KARAF/Roadmap
>
> But before updating the wiki page, I would like to share with you all the
> different topics and provide a global picture overview.
>
> 1/ Short term (3.0.x/3.1.x)
> -------------
> - Fixed and enhancements on the maven-karaf-plugin. It's on my TODO for
> today. It includes several fixes, add more tests, and support of Maven
> 3.1/3.2
> - Usage of commons-daemon. As we are stuck to a old Tanuki JSW wrapper
> (license issue), I prepared the usage of Apache commons-daemon on a branch.
> I will push this branch to let you take a look.
> - Samples and developer guide. I prepared a branch where I replaced the
> demos modules with samples modules. The purpose is to illustrate the
> developer guide (that I refactored/enhanced too) with CDI, JPA, etc samples.
> - Net/minimal distributions. In addition of the "standard" distribution,
> we will provide two other distributions: the net is very very minimal and
> will download all artifacts from remote repository (Internet) at startup,
> on the other hand, minimal distribution contains a minimal system
> repository and allow to easily construct custom distribution.
> - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
> bundles: in Karaf itself, or due to dependency projects (like Pax URL for
> instance). If I think it's good, maybe we want a bit far and, if possible,
> I would reduce the number of bundles started.
> - Own versioning for Spring and Enteprise Karaf Features: now, to upgrade
> to new version of Spring, Hibernate, OpenJPA, etc, we have to release a new
> version of Karaf. Of course, the Karaf features should be provided by the
> projects themselves, but waiting this, I would like to manage Spring and
> Enterprise Karaf features as "standalone". The codebase stays where it's,
> but instead of depending to Karaf parent POM, it will depend directly to
> Apache POM and excluded from the Karaf reactor.
>
> 2/ Middle term (3.1.x/future)
> --------------
> - Blueprint dependency and more usage of pure OSGi/DS. Now, lot of Karaf
> modules depend to blueprint (for IoC or namespace handler). In order to
> minimise the footprint, and avoid some issues (like proxy), it would be
> great to set Blueprint as optional and more use pure OSGi or DS internally
> in Karaf. We should also provide a better "advertising" about DS support.
> - Generic shell commands. Now, projects (like CXF, Camel, etc) depends to
> Karaf shell modules (and console by transitivity). The purpose is:
> 1/ simplify the usage/coding of commands (providing annotation especially)
> 2/ avoid the dependency to blueprint (especially the namespace handler)
> 3/ reduce the dependency
> 4/ provide a better support of Felix Gogo shell in Karaf
>
> Again, the purpose of this e-mail is not to details each section, but to
> provide a global picture. The details will go into the corresponding Jira.
>
> Thoughts ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [PROPOSAL] Roadmap
Posted by Guillaume Nodet <gn...@apache.org>.
2014-02-25 11:28 GMT+01:00 Achim Nierbeck <bc...@googlemail.com>:
> Hi JB,
>
> thanks again for doing a great job to put us all in the right picture again
> :)
>
> Now please see my comments inline:
>
>
> 2014-02-25 10:57 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>
> > Hi all,
> >
> > In the latest weeks, we discussed about different topics and changes for
> > Karaf. We had very interesting different proposals, discussions, etc.
> > However, some discussions were on IRC, so it's not easy for everybody to
> > follow.
> >
> > I would like to summarise the different topics and build a roadmap.
> >
> > I gonna update the roadmap wiki page:
> > https://cwiki.apache.org/confluence/display/KARAF/Roadmap
> >
> > But before updating the wiki page, I would like to share with you all the
> > different topics and provide a global picture overview.
> >
> > 1/ Short term (3.0.x/3.1.x)
> > -------------
> > - Fixed and enhancements on the maven-karaf-plugin. It's on my TODO for
> > today. It includes several fixes, add more tests, and support of Maven
> > 3.1/3.2
> >
>
> nice
>
>
> > - Usage of commons-daemon. As we are stuck to a old Tanuki JSW wrapper
> > (license issue), I prepared the usage of Apache commons-daemon on a
> branch.
> > I will push this branch to let you take a look.
> >
>
> great, though I think we still could go with the "old" one, this shouldn't
> be much of a blocker IMHO
>
>
> > - Samples and developer guide. I prepared a branch where I replaced the
> > demos modules with samples modules. The purpose is to illustrate the
> > developer guide (that I refactored/enhanced too) with CDI, JPA, etc
> samples.
> > - Net/minimal distributions. In addition of the "standard" distribution,
> > we will provide two other distributions: the net is very very minimal and
> > will download all artifacts from remote repository (Internet) at startup,
> > on the other hand, minimal distribution contains a minimal system
> > repository and allow to easily construct custom distribution.
> >
>
> yeah, a net distribution sounds fair though I'm not sure it's good to
> introduce this with a bugfix version.
>
>
> > - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
> > bundles: in Karaf itself, or due to dependency projects (like Pax URL for
> > instance). If I think it's good, maybe we want a bit far and, if
> possible,
> > I would reduce the number of bundles started.
> >
>
> +1, need to find the balance again, I think I've said this before doing
> microbundles just because we can do is not good.
>
>
> > - Own versioning for Spring and Enteprise Karaf Features: now, to upgrade
> > to new version of Spring, Hibernate, OpenJPA, etc, we have to release a
> new
> > version of Karaf. Of course, the Karaf features should be provided by the
> > projects themselves, but waiting this, I would like to manage Spring and
> > Enterprise Karaf features as "standalone". The codebase stays where it's,
> > but instead of depending to Karaf parent POM, it will depend directly to
> > Apache POM and excluded from the Karaf reactor.
> >
>
> like this one a lot, though again I'm a bit ambivalent about this, because
> doing such a "feature" change in a bug-fix version doesn't feel right.
>
>
> >
> > 2/ Middle term (3.1.x/future)
> > --------------
> > - Blueprint dependency and more usage of pure OSGi/DS. Now, lot of Karaf
> > modules depend to blueprint (for IoC or namespace handler). In order to
> > minimise the footprint, and avoid some issues (like proxy), it would be
> > great to set Blueprint as optional and more use pure OSGi or DS
> internally
> > in Karaf. We should also provide a better "advertising" about DS support.
> > - Generic shell commands. Now, projects (like CXF, Camel, etc) depends to
> > Karaf shell modules (and console by transitivity). The purpose is:
> > 1/ simplify the usage/coding of commands (providing annotation
> especially)
> > 2/ avoid the dependency to blueprint (especially the namespace handler)
> > 3/ reduce the dependency
> > 4/ provide a better support of Felix Gogo shell in Karaf
> >
>
> Besides the last point I'm +1
> with 4, I just don't get why this is something Karaf does profit from.
> Could the rather lengthy discussions that have taken place on IRC, and
> really should have taken place on a mailinglist for all to contribute to,
> please be summarized on an extra thread for this?
> I still don't see the value of this.
>
In my last discussion with Christian, we agreed to focus on that.
The use case is to be able to leverage existing gogo commands from other
projects.
A first use case is the SCR commands, we did not have good support for
gogo, so
we ended up rewriting those commands for Karaf. While this is affordable,
I think
it would be better to have gogo commands better supported. The current
goal is
simply to provide visibility of the commands (they are hidden right now)
and basic
completion / description of those commands when annotated with the gogo
commands.
Again, the real use case is not for our commands, but to allow other OSGi
related
projects to be better supported in karaf when they already provide gogo
commands.
I don't think we can achieve the same level of features than when using
karaf commands,
but then it's a choice of the project to either create specific karaf
commands or live with
what we'll have.
>
> regards, Achim
>
>
> >
> > Again, the purpose of this e-mail is not to details each section, but to
> > provide a global picture. The details will go into the corresponding
> Jira.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> > --
> > Jean-Baptiste Onofré
> > jbonofre@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
> >
>
>
>
> --
>
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
> Commiter & Project Lead
> blog <http://notizblog.nierbeck.de/>
>
Re: [PROPOSAL] Roadmap
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi JB,
thanks again for doing a great job to put us all in the right picture again
:)
Now please see my comments inline:
2014-02-25 10:57 GMT+01:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Hi all,
>
> In the latest weeks, we discussed about different topics and changes for
> Karaf. We had very interesting different proposals, discussions, etc.
> However, some discussions were on IRC, so it's not easy for everybody to
> follow.
>
> I would like to summarise the different topics and build a roadmap.
>
> I gonna update the roadmap wiki page:
> https://cwiki.apache.org/confluence/display/KARAF/Roadmap
>
> But before updating the wiki page, I would like to share with you all the
> different topics and provide a global picture overview.
>
> 1/ Short term (3.0.x/3.1.x)
> -------------
> - Fixed and enhancements on the maven-karaf-plugin. It's on my TODO for
> today. It includes several fixes, add more tests, and support of Maven
> 3.1/3.2
>
nice
> - Usage of commons-daemon. As we are stuck to a old Tanuki JSW wrapper
> (license issue), I prepared the usage of Apache commons-daemon on a branch.
> I will push this branch to let you take a look.
>
great, though I think we still could go with the "old" one, this shouldn't
be much of a blocker IMHO
> - Samples and developer guide. I prepared a branch where I replaced the
> demos modules with samples modules. The purpose is to illustrate the
> developer guide (that I refactored/enhanced too) with CDI, JPA, etc samples.
> - Net/minimal distributions. In addition of the "standard" distribution,
> we will provide two other distributions: the net is very very minimal and
> will download all artifacts from remote repository (Internet) at startup,
> on the other hand, minimal distribution contains a minimal system
> repository and allow to easily construct custom distribution.
>
yeah, a net distribution sounds fair though I'm not sure it's good to
introduce this with a bugfix version.
> - Reduce number of bundles: with Karaf 3.0.0, we introduced multiple
> bundles: in Karaf itself, or due to dependency projects (like Pax URL for
> instance). If I think it's good, maybe we want a bit far and, if possible,
> I would reduce the number of bundles started.
>
+1, need to find the balance again, I think I've said this before doing
microbundles just because we can do is not good.
> - Own versioning for Spring and Enteprise Karaf Features: now, to upgrade
> to new version of Spring, Hibernate, OpenJPA, etc, we have to release a new
> version of Karaf. Of course, the Karaf features should be provided by the
> projects themselves, but waiting this, I would like to manage Spring and
> Enterprise Karaf features as "standalone". The codebase stays where it's,
> but instead of depending to Karaf parent POM, it will depend directly to
> Apache POM and excluded from the Karaf reactor.
>
like this one a lot, though again I'm a bit ambivalent about this, because
doing such a "feature" change in a bug-fix version doesn't feel right.
>
> 2/ Middle term (3.1.x/future)
> --------------
> - Blueprint dependency and more usage of pure OSGi/DS. Now, lot of Karaf
> modules depend to blueprint (for IoC or namespace handler). In order to
> minimise the footprint, and avoid some issues (like proxy), it would be
> great to set Blueprint as optional and more use pure OSGi or DS internally
> in Karaf. We should also provide a better "advertising" about DS support.
> - Generic shell commands. Now, projects (like CXF, Camel, etc) depends to
> Karaf shell modules (and console by transitivity). The purpose is:
> 1/ simplify the usage/coding of commands (providing annotation especially)
> 2/ avoid the dependency to blueprint (especially the namespace handler)
> 3/ reduce the dependency
> 4/ provide a better support of Felix Gogo shell in Karaf
>
Besides the last point I'm +1
with 4, I just don't get why this is something Karaf does profit from.
Could the rather lengthy discussions that have taken place on IRC, and
really should have taken place on a mailinglist for all to contribute to,
please be summarized on an extra thread for this?
I still don't see the value of this.
regards, Achim
>
> Again, the purpose of this e-mail is not to details each section, but to
> provide a global picture. The details will go into the corresponding Jira.
>
> Thoughts ?
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>