Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
MIME-Version: 1.0
In-Reply-To: <5316F74F.90002@die-schneider.net>
References: 
 <CAA66TpoysTL1OFYTkjPja8Z4N4D6pXjXh7WY4xuidjN7y8fmrw@mail.gmail.com>
 <5316F74F.90002@die-schneider.net>
From: Guillaume Nodet <gnodet@apache.org>
Date: Wed, 5 Mar 2014 11:51:54 +0100
Message-ID: 
 <CAA66TppUeS=P8b3JHOV7q20NZXRjCwuWeaj=AiqmOqmv8dLGFA@mail.gmail.com>
Subject: Re: [DISCUSS] Where to integrate the new console
To: dev <dev@karaf.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2190c41128a04f3d9d09e

--001a11c2190c41128a04f3d9d09e
Content-Type: text/plain; charset=ISO-8859-1

2014-03-05 11:07 GMT+01:00 Christian Schneider <chris@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
?


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


>
> Christian
>
>
>
>
> On 05.03.2014 10:48, Guillaume Nodet wrote:
>
>> I'd like to start a discussion on how and where (in terms of branch /
>> version) we can integrate the new console I worked on those past days.
>>     https://github.com/gnodet/karaf/tree/console-api/
>>
>> It provides two apis, one for the console and one for the action model.
>>   Both apis have no dependencies at all.   The action model implementation
>> does not depend on the console implementation (only the api) and the
>> console implementation does not depend on the action model at all.
>> The console implementation is mostly a big refactoring of the current
>> console rather than a rewrite bu things are more cleanly separated.  The
>> action model reuses most of the old code too, but uses an extender and a
>> new very light DI system to build the actions.  This light DI allows a
>> better use outside of OSGi, so that I've been able to have all instance:*
>> and ssh:ssh commands to run from bin/shell.
>>
>> The branch is currently in a very good state: all integration test passes.
>>   There are still a few things to do (better logs, optimizations), but
>> those
>> are all very minor.
>>
>> So now, the question is where to integrate this.  The only real (but
>> small)
>> incompatibility is for external projects at build time: if they don't want
>> to migrate to the new action api, they need to depend on the
>> org.apache.karaf.shell.compatibility artifact instead of
>> org.apache.karaf.shell.console, but that's really the only thing to do.
>>
>> So I see several options:
>>    * merge the branch in current master (3.1.x), flag the old console
>> interfaces as deprecated and remove support in 4.x
>>    * create a 4.x branch
>>
>> In addition, we may want to think about the following things:
>>    * what to do about the scr support for the old commands in master: this
>> is new code, but if we switch the api in 3.1.x, it does not necessarily
>> makes sense to support this new code, so better delete it.  My first goal
>> was to prepare the switch to DS but it's not really needed anymore I think
>>    * refactor bin/instance and bin/client to use the new non-osgi console
>> (or get rid of those)
>>    * port all commands to the new api
>>    * consider merging */command and */core into a single bundle as there
>> are
>> no dependencies on blueprint anymore and we use an extender, using
>> optional
>> imports for the apis would make sure bundles can start without the console
>> and would imho help wrt granularity of our bundles
>>
>> Thoughts welcomed !
>>
>> Cheers,
>> Guillaume
>>
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>

--001a11c2190c41128a04f3d9d09e--