karaf, spring, blueprint (Was [Roadmap] 2.x and 3.x ...?)

[Stefano Bagnara <ap...@bago.org>]

David Jencks ha scritto:
> On May 20, 2009, at 7:44 AM, Robert Burrell Donkin wrote:
>> On Wed, May 20, 2009 at 2:23 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>> Robert Burrell Donkin ha scritto:
>>>> On Wed, May 20, 2009 at 11:52 AM, Stefano Bagnara <ap...@bago.org>
>>>> wrote:
>>>>> Robert Burrell Donkin ha scritto:
>>>> this means that sometime soon i won't be running pheonix locally. most
>>>> other mail application developers (who post on list) also seem to be
>>>> using the spring deployment.
>>>
>>> let me clarify that I think that moving to another container is a good
>>> thing. But I don't think that moving to any other container is good. A
>>> choice has to be made and it will be critical for the future. OSGi seems
>>> to be a good option but I still have to see a good configuration service
>>> for osgi components. I don't know OSGi enough to understand if this is a
>>> limit in the "specification" or something that simply has not be done,
>>> or something that exists but I don't know.
> 
> I'm not 100% sure I know what you mean by a configuration service for
> osgi components but...

User interface to application level configuration.
Whenever you embrace a modular framework the main issue is to keep a
central place for the user to configure your modular application.
OSGi try to provide Preferences but IMHO they are too limited or simply
I've yet to see a good usage of them.
Eclipse did something along this, but last time I looked at it (2 years
ago) most of it was eclipse specific code and not usable outside from
eclipse.

> Spring has proposed formalizing much of their xml plan handling stuff as
> the osgi blueprint service.  It's getting a bunch of independent review
> and (IMO) clarification and improvement  and is very close to the final
> spec draft.  There's a TCK.  A few people from servicemix and geronimo
> are working on an apache implementation, currently hosted at geronimo. 
> So I'd recommend using the blueprint service as the "standard" component
> wiring technique.
> 
> I'm not a blueprint expert.... however I think that the service only
> wires up stuff in one bundle, while allowing component references to
> osgi services and publishing components as osgi services.  So, I think
> that rather than having one monolithic server configuration file, you
> can have each piece of the mail server configured in a separate bundle
> and wire the large-scale component assemblies together using services.
> 
> One issue I have not yet found out how to solve in osgi is how to locate
> the server installation on the file system so you can have stuff like
> file-based storage relative to the installation.  For instance in
> geronimo we have a var directory in the server installation and tell
> everyone to put their file based data somewhere inside that, rather than
> trying to store it inside the application itself somehow (as people seem
> to like to do with web apps)  There may be a built in or easy solution
> to this but I don't know what it is yet.

Maybe it worth forgetting at all about phoenix in trunk and try this
way, but this require someone doing this. If there is no one interested
in pushing a new container we can stop discussing. Or at least we can
remove "roadmap" from the subject and simply have a bar conversation
about container/kernels/frameworks.

Reading this one (http://markmail.org/thread/mib3hlxqh7g7h5gm) I
understand karaf is the direct evolution of ServiceMix and that it will
support BluePrint. I liked ServiceMix in past.

If Robert is willing to try karaf for IMAP then I'd love to review that
stuff. IMO is an higher priority to see karaf in IMAP than to have any
featureless release for james.

>> that's fine
>>
>> i'm almost certainly going to move to karaf. i no longer have time for
>> avalon and i'm out of hope that any sort of consensus about new
>> containers for 3.x will be every reached.

You told this also some months ago. My impression was that most people
don't care too much nowadays and that the PMC will agree on anything
that remove phoenix. While I'm not sure I share this vision I'd bet that
a vote (started by you) to move trunk to karaf would pass. Why don't you
simply try it?

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Factoring out libraries to be reused in 2.x and 3.x (Was: karaf, spring, blueprint)

[Stefano Bagnara <ap...@bago.org>]

Robert Burrell Donkin ha scritto:
> everyone knows that i favour factoring out libraries which can be
> reused between 2.x and 3.x but there just isn't consensus support for
> this.

Well. Just try it. I just told you that IMO this is a PITA. If you don't
trust me then just go ahead. I won't veto you in any way.

Indeed if you are able to do this it will be better than nothing, so
simply go ahead.

Just don't ask me to waste my time in a roadmap that I don't share.

Let me see how you backport to 2.3 a module that gives our users *new
features* and *improvements* (I don't care of reviewing src-to-jar
refactorings like the mailet stuff) and you'll have convinced me it
worth reviewing.

Just I don't want anymore to discuss this. Let me see the real library,
the real code, the real patch that make this possible. If you don't
think backporting is a waste of your time I'm happy. I've already warned
you.

I already spent weeks discussing this same thing with Noel 2 years ago,
I'm still waiting for the "vetted backports" to create next-minor.

What you are proposing is what Noel proposed as next-minor 2 years ago.
Like 2 years ago I'm not against it, it simply I'm not going to work
toward something I don't believe/trust.

So, here is my +1 for whatever will bring a release with new features to
our users.

Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: karaf, spring, blueprint (Was [Roadmap] 2.x and 3.x ...?)

[Robert Burrell Donkin <ro...@gmail.com>]

On Wed, May 20, 2009 at 5:39 PM, Stefano Bagnara <ap...@bago.org> wrote:
> David Jencks ha scritto:
>> On May 20, 2009, at 7:44 AM, Robert Burrell Donkin wrote:
>>> On Wed, May 20, 2009 at 2:23 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>> Robert Burrell Donkin ha scritto:
>>>>> On Wed, May 20, 2009 at 11:52 AM, Stefano Bagnara <ap...@bago.org>
>>>>> wrote:
>>>>>> Robert Burrell Donkin ha scritto:
>>>>> this means that sometime soon i won't be running pheonix locally. most
>>>>> other mail application developers (who post on list) also seem to be
>>>>> using the spring deployment.
>>>>
>>>> let me clarify that I think that moving to another container is a good
>>>> thing. But I don't think that moving to any other container is good. A
>>>> choice has to be made and it will be critical for the future. OSGi seems
>>>> to be a good option but I still have to see a good configuration service
>>>> for osgi components. I don't know OSGi enough to understand if this is a
>>>> limit in the "specification" or something that simply has not be done,
>>>> or something that exists but I don't know.
>>
>> I'm not 100% sure I know what you mean by a configuration service for
>> osgi components but...
>
> User interface to application level configuration.
> Whenever you embrace a modular framework the main issue is to keep a
> central place for the user to configure your modular application.
> OSGi try to provide Preferences but IMHO they are too limited or simply
> I've yet to see a good usage of them.
> Eclipse did something along this, but last time I looked at it (2 years
> ago) most of it was eclipse specific code and not usable outside from
> eclipse.

felix has an OSGi configuration service

>> Spring has proposed formalizing much of their xml plan handling stuff as
>> the osgi blueprint service.  It's getting a bunch of independent review
>> and (IMO) clarification and improvement  and is very close to the final
>> spec draft.  There's a TCK.  A few people from servicemix and geronimo
>> are working on an apache implementation, currently hosted at geronimo.
>> So I'd recommend using the blueprint service as the "standard" component
>> wiring technique.
>>
>> I'm not a blueprint expert.... however I think that the service only
>> wires up stuff in one bundle, while allowing component references to
>> osgi services and publishing components as osgi services.  So, I think
>> that rather than having one monolithic server configuration file, you
>> can have each piece of the mail server configured in a separate bundle
>> and wire the large-scale component assemblies together using services.
>>
>> One issue I have not yet found out how to solve in osgi is how to locate
>> the server installation on the file system so you can have stuff like
>> file-based storage relative to the installation.  For instance in
>> geronimo we have a var directory in the server installation and tell
>> everyone to put their file based data somewhere inside that, rather than
>> trying to store it inside the application itself somehow (as people seem
>> to like to do with web apps)  There may be a built in or easy solution
>> to this but I don't know what it is yet.
>
> Maybe it worth forgetting at all about phoenix in trunk and try this
> way, but this require someone doing this. If there is no one interested
> in pushing a new container we can stop discussing. Or at least we can
> remove "roadmap" from the subject and simply have a bar conversation
> about container/kernels/frameworks.
>
> Reading this one (http://markmail.org/thread/mib3hlxqh7g7h5gm) I
> understand karaf is the direct evolution of ServiceMix and that it will
> support BluePrint. I liked ServiceMix in past.
>
> If Robert is willing to try karaf for IMAP then I'd love to review that
> stuff. IMO is an higher priority to see karaf in IMAP than to have any
> featureless release for james.

i'm no longer interested in pushing any container solution: i don't have time

IMHO given the documentation effort required and resources available,
moving users (as opposed to mail application developers) to a new
platform not realistic. an undocumented 3.x running on a novel
container isn't going to offer mail server users a good deal.

but the point is that karaf doesn't require invasive changes to the code base

IMHO it would make most sense to retain 2.x as a pheonix based
solution aimed at mail server users reusing libraries from a spring
based 3.x  aimed at mail application developers

>>> that's fine
>>>
>>> i'm almost certainly going to move to karaf. i no longer have time for
>>> avalon and i'm out of hope that any sort of consensus about new
>>> containers for 3.x will be every reached.
>
> You told this also some months ago. My impression was that most people
> don't care too much nowadays and that the PMC will agree on anything
> that remove phoenix. While I'm not sure I share this vision I'd bet that
> a vote (started by you) to move trunk to karaf would pass. Why don't you
> simply try it?

whenever we start to discuss any moves, it just dissolves. there just
isn't enough consensus.

everyone knows that i favour factoring out libraries which can be
reused between 2.x and 3.x but there just isn't consensus support for
this.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org