On Tue, Jul 12, 2011 at 8:23 AM, Charles Moulliard <[email protected]> wrote:
> Hi Andreas,
>
> I don't think that we will delay the release of Karaf for 2-3 months
> if we develop what I suggest. BTW, If we don't do that, our end users
> will also have to wait maybe a couple of months also to have such
> features at their disposition. So why are we so hurry to deliver
> something when the baby is not ready. Apache Karaf lifecycle of
> releases must be slower compare to Apache Camel, ServiceMix and
> Geronimo as this is the heart/kernel of other projects. So take the
> time about the reflection and prepare cleverly this release.

Yes and no :) The point here is that there are already valuable
features in Karaf (although not that ground shaking; e.g. ways better
Kar support) other projects might want to use; I can only speak from
my point of view here but it would help me with pax-wicket or the
openengsb for example to provide a one-bundle-kar which is also able
to overwrite configuration files helping users to pack everything
together much easier without such heavy use of the internals of karaf
and the other projects :(. But maybe I'm alone with my point of view
here?

>
> Remarks :
> - If Karaf Enterprise Repository covers my point, the answer is yes. I
> don't want to reinvent the wheel but we must provide a repository
> (outside of Apache world) to be able to deploy features for OpenEJB,
> Wicket, Vaadin, Hibernate, ... This will facilitate adoption of OSGI
> world. But don't create a new repo (like OBR or Spring Enterprise
> Repo) just because we would like that Karaf as it but provide real
> added values like a certification program, governance rules to develop
> features files, KAR archive before to deploy them.

We've discussed about this already several times (mostly on IRC and on
the skype birthday meeting; sry for not making this more present; but
there were also 1-2 threads on the ML about this). Basically it's a
two way of integration. At first (maybe Karaf 3.0) it is not more than
an xml files distributing those features files for wicket, vaadin,
.... In a second step (maybe Karaf 3.1) and with the help of Karaf
Cave we can upgrade this to a full OBR supported repository.

> - If karaf project or karaf subproject does not provide an Enterprise
> Web Console, who will do that - a commercial company ? This is
> required by administrators like also scripts to operate / administrate
> the platform. We must also improve mbean components for JMX management
> to better operate Karaf and OSGI Services.

God beware! Except we may profit from it ;) No, fun aside. I'm only
with David here that Karaf (core) might not be the best place for all
those features. I think we can either tackle this as a subproject, but
tbh I think e.g. Aries would be a much better place for such an
enterprise console as they also provide all the enterprise features
for Karaf.

Kind regards,
Andreas

>
> Regards,
>
> Charles Moulliard
>
> Apache Committer
>
> Blog : http://cmoulliard.blogspot.com
> Twitter : http://twitter.com/cmoulliard
> Linkedin : http://www.linkedin.com/in/charlesmoulliard
> Skype: cmoulliard
>
>
>
> On Tue, Jul 12, 2011 at 7:26 AM, Andreas Pieber <[email protected]> wrote:
>> Hey Charles,
>>
>> +1, although this will delay Karaf for at least another 2-3 months at
>> least I'm afraid.
>>
>> On Tue, Jul 12, 2011 at 7:05 AM, Charles Moulliard <[email protected]> 
>> wrote:
>>> That means that we must in this release :
>>> - Simplify the deployment process of the different archives (EAR, WAR,
>>> EBA, JAR, KAR, Spring, Blueprint) and help our end users for doing
>>> that through Maven, OBR, ... - Question : Do we have to support all of
>>> them ? Maybe we could restrict the deployment of the required type
>>> (JAR, Bundle, Spring, Blueprint, WAR ?) and let's project like
>>> Geronimo to take care about EAR, EJB modules ?
>>
>> I don't think that Karaf should be responsible for all types. The base
>> types are quite enough. Aries, Geronimo, SMX could provide more
>> specific deployers for different packages (and we almost have those
>> deployers already). I consider it much more important that .kar files
>> could adapt Karaf in an easier way here.
>>
>>> - Provide a more Enterprise Web Console for operating Karaf -
>>> configuring DataSource(s), web modules, Security, ...
>>
>> Again I'm not sure how far this is the responsibility of Karaf.
>> Although Karaf has the enterprise features file I'm not sure if this
>> is something we really want in the core. We should rather discuss if
>> we shouldn't provide a karaf-enterprise subproject or something
>> similar containing those features (if we want to host this at Karaf at
>> all) (Feel free to create an issue for this point; I'm sure there is
>> none by now).
>>
>>> - Add admin profile to restrict usage of the Karaf commands as we only
>>> support right now a full admin access
>>
>> Interesting idea. This could definitely add some value (I think we're
>> also lacking an issue for that).
>>
>>> - Improve and refactor commands like also the display- e.g. when we
>>> display all commands --> should be grouped and separate from each
>>> other, shortcut displayed at the end, ...
>>
>> Same as above.
>>
>>> - Provide the strategy to be used to perform unit test/integration
>>> with Karaf using pax-exam, pax-exam-2, .... or any other solution
>>> allowing to mock OSGI platform
>>
>> TBH I don't think that this is part of Karaf. We should rather
>> integrate a Karaf Profile for pax-exam2 here (therefore this does not
>> have to come necessarily with Karaf 3. We can tackle this later or
>> earlier as we have time).
>>
>>> - Provide repository of enterprise features (Hibernate, EJB, ...) or
>>> at least governance rules to allow third party projects to develop
>>> such features and pass them into a acceptance program to certified
>>> them according to Karaf releases.
>>
>> Devinitely; this would match the Karaf Enterprise Repository issue, wouldn't 
>> it?
>>
>> Kind regards,
>> Andreas
>>
>>>
>>> + 1 for JB propositions + mine improvements of components
>>> + 1 for a Karaf 3.0 release proposing more enterprise features
>>> - for RC
>>>
>>> Regards,
>>>
>>> Charles Moulliard
>>>
>>> Apache Committer
>>>
>>> Blog : http://cmoulliard.blogspot.com
>>> Twitter : http://twitter.com/cmoulliard
>>> Linkedin : http://www.linkedin.com/in/charlesmoulliard
>>> Skype: cmoulliard
>>>
>>>
>>>
>>> On Tue, Jul 12, 2011 at 12:05 AM, David Jencks <[email protected]> 
>>> wrote:
>>>>
>>>> On Jul 11, 2011, at 5:26 AM, Andreas Pieber wrote:
>>>> <big snip>
>>>>
>>>>> * Karaf profiles & Kar files (IMHO this is one of the most important
>>>>> features for 3.x and not present in the issues by now; there had been
>>>>> considerable work on this by David, but still, we're missing a
>>>>> possibility to start e.g. CXF without modifying some files in etc)
>>>>
>>>> I'm really hoping that 3.0.0 will have the minimal and standard assemblies 
>>>> created using kars/features rather than the old style 
>>>> maven-assembly-plugin.  I haven't been able to work on this for a while 
>>>> but i thought I left it in a state as least as functional as the old-style 
>>>> servers.  The only bit I recall as missing is the legal files.
>>>>
>>>> What are you looking for to start e.g. cxf?  IIRC you can assemble a 
>>>> server including a cxf feature as a boot feature, or add it in later as a 
>>>> regular feature....
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>
>>
>

Reply via email to