2014-03-05 12:12 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:

> On 05.03.2014 11:51, Guillaume Nodet wrote:
>
>> 2014-03-05 11:07 GMT+01:00 Christian Schneider <ch...@die-schneider.net>:
>>
>>  The only problem I see is the incompatibility for old modules.
>>> I propose a slightly different layout:
>>>
>>> Leave the old code in shell.console and move the new api and impl
>>> to a new module. Perhaps shell.console2. Not sure about the name.
>>>
>>> So existing users do not have to change anything. For karaf we can easily
>>> move modules to the new dependency.
>>> For outside projects it would be harder.
>>>
>>>  Yeah, that's definitely a good option.  I just need to find a good name
>> for
>> the new one. I don't really like shell.console2 ...  What about shell.core
>> ?
>>
> +1
> Sounds good
>
>
>>
>>  If we manage to keep the compatibility I would like to see this in the
>>> 3.1
>>> branch and remove the old model for 4.0.
>>>
>>> Btw. What do we do for ActiveMQ? Does their style of using the commands
>>> fit into the new api? I guess not.
>>>
>>>  The ActiveMQ commands do implement CommandWithAction, so they should be
>> fully supported.
>> ActiveMQ could migrate to the new model but that's a different question.
>>
> The problem is that they use AbstractCommand which in turn uses
> DefaultActionPreparator. So they
> are directly exposed to the implementation. If we make this part private
> for the new API then I think it will not work anymore for ActiveMQ.
> The reason is that they adapt their own commands to the karaf ones. So
> they do not use the Action interface.


> I think ActiveMQ might be a good case for using an extended gogo api.


Not sure to follow.  They're currently using the old api and
implementation, so they do work unchanged (I've actually fixed a few things
in the compatibility layer and tested against ActiveMQ).
If ActiveMQ were to migrate, there would be multiple choices:
  * using the new action model: given the small number of commands (6),
it's something that can be done.  It would mean implementing real Action to
leverage completion and help and then
       rebuild the command line and execute the native action inside the
execute() method
  * using the console level Command model: activemq does not need to
implement actions at all and can directly wrap
       native actions into this interface.  Activemq would be responsible
for providing a completer if wanted, but it's not even currently available
  * using plain gogo as now : we just need to make those gogo commands
supported in the console (which isn't done yet, but fairly easy to do)
        but there would be no way to provide completion (but there's none
currently anyway).  It would be roughly similar to the above, without the
ability to provide completion
  * the last option which is what you hint about first needs an extended
api and then support in karaf.  It's currently not an option as this is not
yet implemented
       but it could definitely be considered when available

Guillaume

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

Reply via email to