karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [CONF] Apache Karaf > 2010-09-10 Inline jline and jansi into console project
Date Tue, 07 Feb 2012 13:03:11 GMT
Hi Guillaume,

I understood that it was a decision to inline jline and jansi. So I 
tried to document it as well as I could remember. If we can change that 
I am glad if not I simply want to
document the reasons.

Splitting the console to improve the startup behaviour sounds good. I 
will log it for 3.1. I agree with Claus that the console should ideally 
show when everything important is loaded.
It is very confusing if for example some commands are not yet present.

So if we want to have a single jar and the split then a separate jar for 
usage outside of OSGi sounds the best way to go. This would also allow 
to pack more into the jar if for example
additional commands are needed.

I can help with stabilizing the trunk. The problem is currently I have 
no good overview on what is left to do and the aether problem makes it 
very difficult to test changes. So I try to rather not change much in 
the trunk right now. I hope though your comment does not mean that you 
think documenting architectural decisions is not important. In fact I am 
quite sure that we could save a lot of discussions and have much better 
focus once we documented some of the cornerstones of Karaf. Of course 
some people like you might know most of the decisions and the reasons 
but architecture only works if all understand and follow the decisions.

Christian



Am 07.02.2012 13:22, schrieb Guillaume Nodet:
> Christian,
>
> I think you misunderstood me.  I don't care either way myself and that
> was actually not this way at first.  I did that because that was a
> request from downstream users.  Projects such as ActiveMQ use the
> shell console jar outside of OSGi and it makes their life easier.
>
> If we were in a perfect osgi world, each jar would expose its api and
> hide its implementation.  Unfortunately, that's not the way it works,
> and we need to make trade-off  for technical reasons.
>
> Anyway, one thing which would be more interesting Imho would be to
> split the console from the namespace handler.  One reason is that the
> namespace handler is needed for other commands to be registered, but
> some users have asked that the console is actually started as late as
> possible (using bundle start level).  Given the two are in the same
> bundle, that's not possible right now.
>
> One possible way to solve those two problems would be:
>    1./ split the namespace handler from the console
>    2./ ask the activemq guys what they think about the single jar problem
>    3./ if they really need it, provide a second packaging bundle which
> would include the two splitted bundles + jansi / jline
>
> Also, if I may suggest, if you have some free time, maybe you could
> check with Jean-Baptiste who is trying to stabilize the trunk for an
> eventual release ...
>
> On Tue, Feb 7, 2012 at 11:10,<confluence@apache.org>  wrote:
>> 2010-09-10 Inline jline and jansi into console project
>>
>> Page added by Christian Schneider
>>
>>
>> The Karaf console project inlines all classes from jline and jansi to
>> provide a single jar that can be used easily outside Karaf.
>>
>> Pros
>>
>> For standalone usage the console jar can be called using java -jar
>>
>> Cons
>>
>> Inlining other projects breaks the module concept where each module tries to
>> keep as many things private as possible
>> Ties console to one specific version of jline and jansi
>> The standalone jar could also be built individually. So in OSGi the jars
>> could be separate
>>
>> Who supported this decision
>>
>> Guillaume Nodet
>> *
>>
>> h2 Who was against it
>>
>> Christian Schneider
>> *
>>
>> References
>>
>> https://issues.apache.org/jira/browse/KARAF-1102
>> https://issues.apache.org/jira/browse/KARAF-144
>>
>> Change Notification Preferences
>> View Online | Add Comment
>
>


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message