karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@apache.org>
Subject Re: Ideas about karaf and gogo commands
Date Sat, 01 Mar 2014 00:56:49 GMT
Following up on what I did, I just pushed a private branch to github with
this new experimental console.
I haven't changed the packaging, so everyhing it still in shell/console
bundle in a different package root to split things.
   https://github.com/gnodet/karaf/tree/console-api

The whole api is available with this commit:

https://github.com/gnodet/karaf/commit/b87c82748ef1603e0b4e6bb85d785d1b0ee28a28
and the following tree:

https://github.com/gnodet/karaf/tree/console-api/shell/console/src/main/java/org/apache/karaf4/shell/api
So, it consists in two packages which are completely independent and have
no dependencies.
  * api/action : the action model
  * api/console : the console api

The implementation is available with this commit:

https://github.com/gnodet/karaf/commit/3964a82c9de7e235dd5057e0107c46b77485c1ab
It's quite a big commit, mostly because there are no ties with the previous
console implementation, so a lot of classes have been copied so that things
are isolated and clean.
So there are 2 parts in the implementation:
   * the action model implementation which depends on the action api and
the console api
   * the console implementation which depends on the console api only and
is usable either with osgi (just plain osgi api, not blueprint powered) or
standalone

Note that "old" commands (i.e. those we have now in master) are completely
functional through a very small bridge

https://github.com/gnodet/karaf/tree/console-api/shell/console/src/main/java/org/apache/karaf4/shell/impl/console/osgi/compat

There are still a bunch of things to do, but it's already usable, so I
wanted to share it.
Btw, the branch compiles and run correctly, the console has all available
commands but ssh which is really tied to the old console and need some real
work to migrate.
In short, it brings:
  * 2 clean and independent apis for actions and console
  * support for the karaf 2.x and 3.x models
  * ability to support new command model (such as gogo) quite easily
  * ability to support our commands on a different console implementation
(that could be a wrapper on gogo-shell for example)
  * even independent of osgi : not done yet, but the bin/instance script
could actually run a real console instead of rewriting a small launcher

Have a good week-end !





2014-02-27 13:14 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net>:

> Hi Guillaume,
>
> it sounds good. Thanks for the update.
>
> Regards
> JB
>
>
> On 02/27/2014 12:54 PM, Guillaume Nodet wrote:
>
>> I'm experimenting with the API i proposed earlier, but what I'm playing
>> with right now is, in addition to a cleaner Action model API, an
>> abstraction of the console, so that the command model only depends on the
>> console api.
>> This way, we should be able to have an action model that works on a
>> pluggable console implementation.
>> It should allow using actions or any other model (plain gogo) on top of a
>> console which can run in osgi, non osgi, gogo or not and jline or not.
>> I'll keep you posted on my experiments.
>>
>> Guillaume
>>
>>
>>
>> 2014-02-27 11:26 GMT+01:00 Christian Schneider <chris@die-schneider.net>:
>>
>>  If my proposals sounded like THE solution I must apologize. It was not my
>>> intention. Somehow my style of writing things often seem to be perceived
>>> in
>>> this way. I am aware of this and am trying to improve my style. If you
>>> hit
>>> such a mail by me I will be happy about some personal feedback.
>>>
>>> About the proposals. They are indeed rather far from being even a
>>> coherent
>>> solution. I am still experimenting and am not even sure about the best
>>> way
>>> for a command api from my point of view. My intent was just to summarize
>>> the current situation and give some inspiration on directions for
>>> improvement. I also wanted to inform you what I intend to look into. One
>>> thing we could already work on is to find the goals of the karaf
>>> community
>>> regarding the command api. I listed the goals I have but I would like to
>>> hear what goals others have for a future API and solution. I think in
>>> design there is no absolute good and bad. You can only judge a design
>>> based
>>> on the goals you have. So I think the most important thing we can do
>>> right
>>> now is to define the goals as a community.
>>>
>>> Christian
>>>
>>>
>>>
>>> 2014-02-27 9:56 GMT+01:00 Jean-Baptiste Onofré <jb@nanthrax.net>:
>>>
>>>  Hi,
>>>>
>>>> gentlemen, calm down and try to focus on the ways to improve Karaf.
>>>>
>>>> Christian presented a proposal for discussion, Achim replies with
>>>> pros/cons: it's the Apache way and that's why it has to be discussed.
>>>> We just have to say in a polite and constructive discussion.
>>>>
>>>> When we propose a new feature/change, we have to be ready to accept
>>>> critics (and don't think we have THE solution, maybe we don't see the
>>>> complete picture), and on the other hand, when describing pros/cons on a
>>>> proposal, it should be done in a gentle, polite, and constructive way.
>>>>
>>>> I think that Christian proposal has very interesting values, especially
>>>> about a commands API. The details should be polished (for instance, I'm
>>>>
>>> not
>>>
>>>> yet sure that gogo shell is good basement), but we can move on and look
>>>> forward on some detailed discussion.
>>>>
>>>> Achim also expressed a good point: keep it simple, not reinvent the
>>>>
>>> wheel.
>>>
>>>> I take it more like a general reminder for all of us: we did a great
>>>> work
>>>> in Karaf in term of end-user convenience, flexible features, etc. Some
>>>>
>>> part
>>>
>>>> are very "Karaf centric", and it makes sense to provide something more
>>>> generic and flexible if you want to increase the popularity of Karaf. On
>>>> the other hand, those changes must not break the existing and
>>>> implemented
>>>> as an atomic plant ;)
>>>>
>>>> So, let express constructive critics (a critic can be negative or
>>>> positive) and move forward all together to build a better Karaf.
>>>>
>>>> As reminder: personal promotion, selfish, pedantic, etc don't take place
>>>> in Apache projects (and OpenSource projects in general). We are
>>>> dedicated
>>>> to the users and the community, always listen our team mates, committed
>>>>
>>> on
>>>
>>>> the project. The project doesn't belong to anyone, it belongs to
>>>>
>>> everybody,
>>>
>>>> including the users.
>>>>
>>>> Thanks guys
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 02/27/2014 09:21 AM, Christian Schneider wrote:
>>>>
>>>>  Hi Achim,
>>>>>
>>>>> I accept you opinion yet with some disappointment about your ignorance
>>>>>
>>>> of
>>>
>>>> the outside world.
>>>>> I hope this does not refelect the whole karaf community.
>>>>>
>>>>> JB and Guillaume seem to be fine with improving the gogo support.
>>>>>
>>>>> As for the KISS principle. I think the gogo command style follows this
>>>>> principle better then the karaf Action style. You can simply export a
>>>>>
>>>> gogo
>>>
>>>> command class as a service. So you are really just exposed to the API.
>>>>>
>>>> For
>>>
>>>> DS this also means
>>>>> that there is no need for any extender. Can it be more simple like
>>>>> that?
>>>>>
>>>>> In our Action case there always has to be a Command adapter that needs
>>>>>
>>>> to
>>>
>>>> be pulled up and exported as a command. Guillaume did some great work to
>>>>> make the usage of Action in karaf as easy as possible and it helps us
a
>>>>> lot.
>>>>> Still the gogo model is just simpler in its core. So I think we should
>>>>>
>>>> at
>>>
>>>> least consider it too. Especially when we think about a new API for
>>>>>
>>>> karaf
>>>
>>>> 4.
>>>>>
>>>>> What I miss from all your mails is some real technical arguments. Your
>>>>> arguments are just I don't need it and I don't care about the outside
>>>>> world. This style of discussion reminds me more of politics than
>>>>> apache.
>>>>> As
>>>>> said above I accept this as your opinion. So I am fine if you do not
>>>>>
>>>> want
>>>
>>>> to go into more details.
>>>>>
>>>>> Christian
>>>>>
>>>>>
>>>>> 2014-02-27 6:58 GMT+01:00 Achim Nierbeck <bcanhome@googlemail.com>:
>>>>>
>>>>>   I thought about if I really should answer this, but here we go
>>>>>
>>>>>>
>>>>>>
>>>>>> 2014-02-26 13:43 GMT+01:00 Christian Schneider <
>>>>>>
>>>>> chris@die-schneider.net
>>>
>>>>  :
>>>>>>>
>>>>>>
>>>>>>   Hi Achim,
>>>>>>
>>>>>>>
>>>>>>> have you ever asked any developer of commands outside karaf what
he
>>>>>>> wants
>>>>>>> or needs?
>>>>>>> You asume yagni but is it perhaps more like iagni ?
>>>>>>>
>>>>>>>
>>>>>>>  Actually I don't care about outside Karaf, cause if you want
the
>>>>>>
>>>>> features
>>>
>>>> use karaf. If you can't, stop whining and find a way to use Karaf. It's
>>>>>> as
>>>>>> simple as that
>>>>>> If that is still not possible, well live with it. Live isn't
>>>>>>
>>>>> Pony-Ranch,
>>>
>>>> usually you don't get what you want and have to live with it, and make
>>>>>> the
>>>>>> best of it!
>>>>>>
>>>>>>
>>>>>>
>>>>>>  Are you really sure that an external developer could live with the
>>>>>>>
>>>>>> only
>>>
>>>>  two alternatives you would give them?
>>>>>>> - Loose all extended karaf features
>>>>>>> - Create two sets of commands
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    I also think we should separate two things here. What I spend
my
>>>>>> time
>>>>>>
>>>>>>>
>>>>>>>  with
>>>>>>
>>>>>>  is mainly my concern.
>>>>>>> The other thing is the impact on karaf. I clearly understand
that you
>>>>>>>
>>>>>>>  fear
>>>>>>
>>>>>>  a more complicated code in karaf.
>>>>>>> I can assure you that I will do my best to keep the code simple
to
>>>>>>> better
>>>>>>> support gogo commands.
>>>>>>>
>>>>>>>
>>>>>>>   You are absolutely right, it is not my business to take care
what
>>>>>>> you
>>>>>>>
>>>>>> do
>>>>>> the whole day, you might as well drill yourself a hole in the head,
I
>>>>>> actually don't care.
>>>>>>
>>>>>> But what I do care is, does it put a bigger value into Karaf, does
it
>>>>>> move
>>>>>> Karaf forward.
>>>>>> Is it worth all the hassle, that I do care.
>>>>>> And with only looking at Karaf I don't see the value!
>>>>>>
>>>>>> If you want to change gogo, go to felix, discuss it there find a
way
>>>>>> to
>>>>>> get
>>>>>> the felix people to like your ideas. If you're done with that, then
we
>>>>>> might have a benefit to use a common implementation.
>>>>>> But OOPS, you still have to convince the eclipse people to use it
>>>>>> also.
>>>>>> Now
>>>>>> that is something I'd call a challenge.
>>>>>>
>>>>>>
>>>>>>   There is also a need for a new command API in karaf 4 which
>>>>>> Guillaume
>>>>>>
>>>>>>>
>>>>>>>  also
>>>>>>
>>>>>>  looks into. I see some good reasons why maybe an extended gogo API
>>>>>>> may
>>>>>>> be
>>>>>>> the best fit for us.
>>>>>>> Trying to achieve better support for gogo commands would also
give us
>>>>>>>
>>>>>> a
>>>
>>>>  good chance to see how this alternative would work. So it might help
>>>>>>>
>>>>>> us
>>>
>>>>  decide
>>>>>>> about the future API.
>>>>>>>
>>>>>>>
>>>>>>>   As much I've seen so far, all of Guillaumes improvements did
focus
>>>>>>> on
>>>>>>>
>>>>>> KISS.
>>>>>>   From yours I can't say that.
>>>>>>
>>>>>>
>>>>>>   Christian
>>>>>>
>>>>>>>
>>>>>>> Am 26.02.2014 09:48, schrieb Achim Nierbeck:
>>>>>>>
>>>>>>>   But again, this is a propblem which doesn't really concern
Karaf.
>>>>>>> If
>>>>>>>
>>>>>>>> Camel, CXF, ActiveMQ do need other commands, go create those
>>>>>>>>
>>>>>>> "striped"
>>>
>>>>  commands there, use-case solved (Keep It Simple, Stupid - KISS) [1].
>>>>>>>>
>>>>>>> So
>>>
>>>>
>>>>>>>>  you
>>>>>>>
>>>>>>
>>>>>>  should rather spent your time productive on reducing the scope of
the
>>>>>>>
>>>>>>>> commands then another POC that's just another YAGNI (You
Aren't
>>>>>>>> Gonna
>>>>>>>>
>>>>>>>>  Need
>>>>>>>
>>>>>>
>>>>>>  It) [2]
>>>>>>>
>>>>>>>>
>>>>>>>> I'm repeating myself, I haven't seen such people yet, still
go back
>>>>>>>>
>>>>>>> to
>>>
>>>>
>>>>>>>>  the
>>>>>>>
>>>>>>
>>>>>>  basics if needed, provide Commands that fit the environment to run
>>>>>>> in,
>>>>>>>
>>>>>>>> instead over-complicating the stuff that works for Karaf.
>>>>>>>>
>>>>>>>>
>>>>>>>> regards, Achim
>>>>>>>>
>>>>>>>> [1] - http://en.wikipedia.org/wiki/KISS_principle
>>>>>>>> [2] - http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>   Christian
>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Christian Schneider
>>>>>>>>> http://www.liquid-reality.de
>>>>>>>>>
>>>>>>>>> Open Source Architect
>>>>>>>>> http://www.talend.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>  --
>>>>>>>    Christian Schneider
>>>>>>> http://www.liquid-reality.de
>>>>>>>
>>>>>>> Open Source Architect
>>>>>>> Talend Application Integration Division 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/>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>  --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>>
>>>
>>>
>>> --
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de<
>>> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e
>>> 46&URL=http%3a%2f%2fwww.liquid-reality.de
>>>
>>>>
>>>>
>>> Open Source Architect
>>> http://www.talend.com<
>>> https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e
>>> 46&URL=http%3a%2f%2fwww.talend.com
>>>
>>>>
>>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message