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/>