Thanks JB I might have gotten a bit sarcastic over the time. Sorry for disturbing the mailinglist.
regards, Achim 2014-02-27 9:56 GMT+01:00 Jean-Baptiste Onofré <j...@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 <bcanh...@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 <ch...@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é > jbono...@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/>
