You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Bernd Fondermann <bf...@brainlounge.de> on 2007/10/07 19:47:02 UTC
[VOTE] Move spring-deployment module to TRUNK
Hi,
As proposed in a previous mail, we should make the spring-deployment
part of trunk.
As a consequence, we would be able to release a Spring-container-based
Server runtime besides our regular Avalon-based.
Please cast your vote to execute
svn cp
https://svn.apache.org/repos/asf/james/server/sandbox/spring-integration/spring-deployment
https://svn.apache.org/repos/asf/james/server/trunk
[] +1, let's include the spring-deployment code in trunk
[] 0, I don't care
[] -1, Veto! Don't include the spring-deployment code in trunk and in
upcoming releases
This vote will run for an entire week for code review and will be
tallied not before 2007-10-14 20:00 GMT
Thanks for voting,
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Kevin Jackson <fo...@gmail.com>.
> > [] +1, let's include the spring-deployment code in trunk
> > [] 0, I don't care
> > [] -1, Veto! Don't include the spring-deployment code in trunk and in
> > upcoming releases
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Serge Knystautas <sk...@gmail.com>.
On 10/7/07, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Hi,
>
> As proposed in a previous mail, we should make the spring-deployment
> part of trunk.
> As a consequence, we would be able to release a Spring-container-based
> Server runtime besides our regular Avalon-based.
>
> Please cast your vote to execute
> svn cp
> https://svn.apache.org/repos/asf/james/server/sandbox/spring-integration/spring-deployment
> https://svn.apache.org/repos/asf/james/server/trunk
>
> [] +1, let's include the spring-deployment code in trunk
> [] 0, I don't care
> [] -1, Veto! Don't include the spring-deployment code in trunk and in
> upcoming releases
+1
--
Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Bernd Fondermann wrote:
> Hi,
>
> As proposed in a previous mail, we should make the spring-deployment
> part of trunk.
> As a consequence, we would be able to release a Spring-container-based
> Server runtime besides our regular Avalon-based.
>
> Please cast your vote to execute
> svn cp
> https://svn.apache.org/repos/asf/james/server/sandbox/spring-integration/spring-deployment
> https://svn.apache.org/repos/asf/james/server/trunk
>
> [] +1, let's include the spring-deployment code in trunk
> [] 0, I don't care
> [] -1, Veto! Don't include the spring-deployment code in trunk and in
> upcoming releases
Just for clarification: This is a large portion of code to be moved. We
would still argue about the details of the implementation afterwards,
because at least Stefano pointed out he would only take a deeper look
then. But maybe there are others who would rather like to have a look at
the code now.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Norman Maurer <no...@apache.org>.
Am Sonntag, den 07.10.2007, 19:47 +0200 schrieb Bernd Fondermann
>
> [x] +1, let's include the spring-deployment code in trunk
bye
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Bernd Fondermann wrote:
> Please cast your vote to execute
> svn cp
> https://svn.apache.org/repos/asf/james/server/sandbox/spring-integration/spring-deployment
> https://svn.apache.org/repos/asf/james/server/trunk
>
[X] +1, let's include the spring-deployment code in trunk
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
+1
Vincenzo
Bernd Fondermann wrote:
> Hi,
>
> As proposed in a previous mail, we should make the spring-deployment
> part of trunk.
> As a consequence, we would be able to release a Spring-container-based
> Server runtime besides our regular Avalon-based.
>
> Please cast your vote to execute
> svn cp
> https://svn.apache.org/repos/asf/james/server/sandbox/spring-integration/spring-deployment
> https://svn.apache.org/repos/asf/james/server/trunk
>
> [] +1, let's include the spring-deployment code in trunk
> [] 0, I don't care
> [] -1, Veto! Don't include the spring-deployment code in trunk and in
> upcoming releases
>
> This vote will run for an entire week for code review and will be
> tallied not before 2007-10-14 20:00 GMT
>
> Thanks for voting,
>
> Bernd
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/7/07, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Hi,
>
> As proposed in a previous mail, we should make the spring-deployment
> part of trunk.
> As a consequence, we would be able to release a Spring-container-based
> Server runtime besides our regular Avalon-based.
>
> Please cast your vote to execute
> svn cp
> https://svn.apache.org/repos/asf/james/server/sandbox/spring-integration/spring-deployment
> https://svn.apache.org/repos/asf/james/server/trunk
>
> [] +1, let's include the spring-deployment code in trunk
+1
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Bernd Fondermann <be...@googlemail.com>.
On 10/10/07, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
> > On 10/9/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
> >> On 10/9/07, Bernd Fondermann <be...@googlemail.com> wrote:
> >>> Let's face it - there will be nothing what could remind you of Phoenix
> >>> in the combined code base.
> >>> But it probably will work similar to Spring IoC-Container. Much
> >>> flexibility, simplicity.
> >>> Anyway, every container apart from Phoenix will be fine.
> >> pheonix is tightly coupled with the excaliber components we use.
> >
> > it's funny you write that. "the IoC container is tightly coupled with
> > its components" ;-)
> > James is not dependend on Phoenix (the only part I managed to get
> > around in James/Spring), but it is very tightly coupled indeed with
> > excalibur components. We'd probably have to rewrite much of our code
> > to loosen these strings.
> I don't agree with Robert and you about Phoenix being tightly coupled
> with components we use.
> There is nothing, but Avalon interfaces that really bind us to Phoenix,
> and your spring module is the final proof.
Right. That's also what I think. I just was picking at Roberts wording there.
> I have difficult understanding what you (you all) want to refactor when
> you talk about POJO, avalon, excalibur by mixing issues. Can we agree on
> the above classification for our "dependencies" and be more specific in
> the discussion?
Yes, we are mixing up different things sometimes. But hey, this only
shows how complicated our server architecture is.
I understood Robert's statement about refactoring components as being
a statement about what might should happen inside excalibur, not here
at James. (If it will happen, who knows, I doubt it, but you happen to
be at the Excalibur PMC... ;-))
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> On 10/9/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
>> On 10/9/07, Bernd Fondermann <be...@googlemail.com> wrote:
>>> Let's face it - there will be nothing what could remind you of Phoenix
>>> in the combined code base.
>>> But it probably will work similar to Spring IoC-Container. Much
>>> flexibility, simplicity.
>>> Anyway, every container apart from Phoenix will be fine.
>> pheonix is tightly coupled with the excaliber components we use.
>
> it's funny you write that. "the IoC container is tightly coupled with
> its components" ;-)
> James is not dependend on Phoenix (the only part I managed to get
> around in James/Spring), but it is very tightly coupled indeed with
> excalibur components. We'd probably have to rewrite much of our code
> to loosen these strings.
I don't agree with Robert and you about Phoenix being tightly coupled
with components we use. IMHO it is a good coincidence IF Phoenix uses
some of the same components we also decided to use to build JAMES
Server. This means less memory used as the container and the contained
application share something.
There is nothing, but Avalon interfaces that really bind us to Phoenix,
and your spring module is the final proof.
>> it is
>> possible that excaliber may be refactored into pojos and avalon
>> bindings.
>
> I'd like to see that happen. Anyone already working on that or is this
> only in theory?
>
> Bernd
First we have to make a classification:
Excalibur jars are often splitted in api and impl: API does not have
dependencies on Avalon or anything container related. IMPLs often refer
some activity marker interface (Disposable) and the Avalon Logger (to be
injected). IMHO you can use them like any POJO: inject the dependencies
and use them.
In many cases excalibur code become some commons-* utility: there is a
documentation page, somewhere, that explain what common jar deprecated
each excalibur library.
Cornerstone are instead integration components to simplify using the
libraries above in a Avalon/Phoenix environment. They are very simple
jars often containing only 1 interface and 1 implementation, and this is
a common result of IoC frameworks. If you don't use them or you don't
include such "utility classes" in your main code you will end up writing
utility code for your framework. This also happens in spring. Spring try
to provide utility classes for most common libraries out there, but
often projects have to provide their own:
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/mina/mina-integration-spring/1.1.3/
Sometimes our components directly extends cornerstone components: we do
this because we extend that code and not because we need to satisfy some
special obsolete container requirement.
Let me be clear: I don't like Phoenix as it is obsolete code no more
mantained, but I don't really think that Spring is the panacea and most
of the problems people is reporting about Phoenix are there also with
Spring.
Too much times we use Avalon instead of Phoenix and viceversa, but here
we also have Excalibur and Cornerstone and each one have 2 kind of
dependency (api/descriptors and implementation). I would say that JAMES
is currently distributed with:
- avalon-api
- avalon-impl
- various excalibur-api
- various excalibur-impl
- various cornerstone-api
- various cornerstone-impl
- some phoenix block descriptor (I consider them like an API, even if it
is not introduce direct dependencies like an interface)
- phoenix itself.
The spring module replaced phoenix itself and ATM it keep using the
phoenix configuration files and descriptors.
I have difficult understanding what you (you all) want to refactor when
you talk about POJO, avalon, excalibur by mixing issues. Can we agree on
the above classification for our "dependencies" and be more specific in
the discussion?
Many times in past I started working on extracting the whole avalon
stuff (all of the above dependencies) from our base code to Avalon
wrappers, but, as I wrote multiple times, there are JAMES core
components using avalon interfaces as THEIR OWN way to manage lifecycle
for their contained/managed objects.
So the avalon "extraction" would have required a big big big refactoring
and every time I started discussing each step concretely discussion lead
to nothing.
IMHO the only way to go is replace one thing at a time (one of that
dependencies at a time): the only thing we partially did is to support
setter injection for services in addition to the ServiceManager. This is
a first step. This allow other users of the code to not understand what
ServiceManager is (and depend on it) and to directly work with the real
dependencies.
Then you have the Log issue: you can use/inject the logger from
commons-logging but they don't support child loggers, so either you
create your own interface and implements it via commons-logging, or you
simply keep using avalon logger and implements it via commons-logging
(like you already do in the spring module, right?).
Then you have the avalon Context: I think I managed to isolate the
context usage to the AvalonFileSystem block and removed it from everywhere.
As I wrote in past, and I rephrase it for the newer committers, I do not
favor removing "avalon framework api" interfaces from our code by simply
creating new interfaces in our packages and use them. IMHO if we do not
need different interfaces it does not make sense to duplicate avalon
interfaces: this add incompatibility with the avalon world, and does not
add any advantage.
IMHO avalon interfaces are the last thing to care about, IF and ONCE we
won't use phoenix anymore and we'll have removed any outdated components.
The "complicate" steps to remove avalon can be found looking for the
ContainerUtil class usage. They are the key of our usage of the avalon
container logic INSIDE our components. Once they are factored out from
the code (using Factories or any other pattern you can think about) then
everything else will be much smoother. Keep talking about POJOs,
avalon-free, and other similar thing without solving this concrete step
is something we already did for years. And maybe this is not so
complicate: it requires someone that do it and most of others to be
happy to see many changes committed.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Bernd Fondermann <be...@googlemail.com>.
On 10/9/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
> On 10/9/07, Bernd Fondermann <be...@googlemail.com> wrote:
> > Let's face it - there will be nothing what could remind you of Phoenix
> > in the combined code base.
> > But it probably will work similar to Spring IoC-Container. Much
> > flexibility, simplicity.
> > Anyway, every container apart from Phoenix will be fine.
>
> pheonix is tightly coupled with the excaliber components we use.
it's funny you write that. "the IoC container is tightly coupled with
its components" ;-)
James is not dependend on Phoenix (the only part I managed to get
around in James/Spring), but it is very tightly coupled indeed with
excalibur components. We'd probably have to rewrite much of our code
to loosen these strings.
> it is
> possible that excaliber may be refactored into pojos and avalon
> bindings.
I'd like to see that happen. Anyone already working on that or is this
only in theory?
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/9/07, Bernd Fondermann <be...@googlemail.com> wrote:
> Let's face it - there will be nothing what could remind you of Phoenix
> in the combined code base.
> But it probably will work similar to Spring IoC-Container. Much
> flexibility, simplicity.
> Anyway, every container apart from Phoenix will be fine.
pheonix is tightly coupled with the excaliber components we use. it is
possible that excaliber may be refactored into pojos and avalon
bindings.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Bernd Fondermann <be...@googlemail.com>.
Let's face it - there will be nothing what could remind you of Phoenix
in the combined code base.
But it probably will work similar to Spring IoC-Container. Much
flexibility, simplicity.
Anyway, every container apart from Phoenix will be fine.
Sorry for ranting ;-)
Bernd
On 10/8/07, Noel J. Bergman <no...@devtech.com> wrote:
> See: http://wiki.apache.org/incubator/ComposerProposal
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> On 10/10/07, Stefano Bagnara <ap...@bago.org> wrote:
>> As an example of phoenix advanced components, phoenix provides a
>> Beanshell based kernel that you can access with a console to manage the
>> container and the contained applications dynamically.
>
> Phoenix is a very mature and capable container. Spring cannot
> supersede every possible feature of Phoenix or any other technology.
> And I am not saying that Spring is equivalent to Phoenix in every
> single example you gave. But nevertheless, I'd like to give some
> references where everybody interested might start reading...
I reply to the pointers you gave so to make it more clear what I was
talking about, but I think we mostly agree on the Phoenix vs Spring
issue and the 2 specific issues are not so important now.
> for scripting and BeanShell support, see Spring Reference Chapter 24. esp. 24.3.
I don't know every Spring aspect this well, but I think this is different.
The Beanshell kernel module for Phoenix gives you an *interactive* shell
where you can remotely login and manage apps/components via beanshell.
Spring chapter 24 is instead (if I understand it correctly) about
writing new components using scripting/dynamic languages.
>> Phoenix has an HTTP adaptor on the ServiceManager that allow you to
>> access the JMX services via web.
>
> see Spring Reference Chapters 17.4 and 20.
I see JMX export and HTTP support, but I don't see an out of the box
solution that gives me a way to point my a simple browser there, see
some information, restart some component and so on. I'm sure you can do
this integrating MX4J or other tools, but at the moment in phoenix I
uncomment few lines in the configuration file, with spring I should
start reading 2 chapters...
>> Not everything in this list will make me veto a proposal to use spring
>> as our main deployment and forget about phoenix, but some of them are
>> important, and this was mainly to make it clear that spring is not the
>> panacea.
>
> Alright. My basic idea behind the spring-deployment is /choice/, to
> offer our users new ways to integrate James with their own or third
> party software.
> Pheonix-deployment module will live on as long as someone is maintaining it.
> At least I myself will never propose to deprecate it.
I will do, once I'll see a complete alternative: supporting multiple
deployment is (IMHO) a waste of already limited (human) resources.
Thank you,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Bernd Fondermann <be...@googlemail.com>.
On 10/10/07, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
> > On 10/8/07, Noel J. Bergman <no...@devtech.com> wrote:
> >> I will go on record that I oppose a move to Spring, and have said so on
> >> multiple occassions. However, I do not oppose optional support for Spring.
> >
> > The Phoenix deployment will live on. All the users having their own
> > components and whatever customizations will be supported. For new
> > users starting to use James there is no fundamental advantage chosing
> > one deployment over the other. Except if they already have Spring
> > components (or POJOs) they'd like to integrate with.
>
> It will take a bit for spring to catch up with all the features our user
> may currently use in our phoenix deployment.
That's right. At the same time it offers, IMHO, ease-of-use and
integration capabilities the phoenix deployment does not provide.
> The spring deploymnet will need the scripts for unix and windows, the
> wrappers to run it as a service, it will need the integration with
> Commons Daemon.
Agreed.
> As an example of phoenix advanced components, phoenix provides a
> Beanshell based kernel that you can access with a console to manage the
> container and the contained applications dynamically.
Phoenix is a very mature and capable container. Spring cannot
supersede every possible feature of Phoenix or any other technology.
And I am not saying that Spring is equivalent to Phoenix in every
single example you gave. But nevertheless, I'd like to give some
references where everybody interested might start reading...
for scripting and BeanShell support, see Spring Reference Chapter 24. esp. 24.3.
> Phoenix has an HTTP adaptor on the ServiceManager that allow you to
> access the JMX services via web.
see Spring Reference Chapters 17.4 and 20.
> Phoenix supports classloader isolations between multiple applications
> deployed inside it
Spring does not offer that, AFAIK, but if you already have separate
classloaders, you can have one BeanFactory for each. So it does not
offer classloader isolation, but supports it.
> Not everything in this list will make me veto a proposal to use spring
> as our main deployment and forget about phoenix, but some of them are
> important, and this was mainly to make it clear that spring is not the
> panacea.
Alright. My basic idea behind the spring-deployment is /choice/, to
offer our users new ways to integrate James with their own or third
party software.
Pheonix-deployment module will live on as long as someone is maintaining it.
At least I myself will never propose to deprecate it.
> OT: In almost an year we didn't add anything SMTP/POP3 related
> neither improved our support for mailets (this is not a critic to you or
> your cool spring module, but something our PMC should take into account)
yes, but I don't see the protocols as the only important part of the
server. working at the fundamental architecture and making it more
manageable will also open up new opportunities to innovate in the
protocol section. Service interfaces could also be improved. For
example, with the new modularized project layout we could have two
SMTP implementations side-by-side, one proven, one experimental - just
like we seem to have two different deployments.
I'm not an expert on mail protocols, so I'll work on other parts of the project.
Bernd
>
> Stefano
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> On 10/8/07, Noel J. Bergman <no...@devtech.com> wrote:
>> I will go on record that I oppose a move to Spring, and have said so on
>> multiple occassions. However, I do not oppose optional support for Spring.
>
> The Phoenix deployment will live on. All the users having their own
> components and whatever customizations will be supported. For new
> users starting to use James there is no fundamental advantage chosing
> one deployment over the other. Except if they already have Spring
> components (or POJOs) they'd like to integrate with.
It will take a bit for spring to catch up with all the features our user
may currently use in our phoenix deployment.
The spring deploymnet will need the scripts for unix and windows, the
wrappers to run it as a service, it will need the integration with
Commons Daemon.
As an example of phoenix advanced components, phoenix provides a
Beanshell based kernel that you can access with a console to manage the
container and the contained applications dynamically.
Phoenix has an HTTP adaptor on the ServiceManager that allow you to
access the JMX services via web.
Phoenix supports classloader isolations between multiple applications
deployed inside it
Not everything in this list will make me veto a proposal to use spring
as our main deployment and forget about phoenix, but some of them are
important, and this was mainly to make it clear that spring is not the
panacea.
On the container side I keep monitoring the directory project, because I
think ApacheDS and JAMES Server could share a lot, and "following" a
more active project could help us in working on our real goals: the mail
handling. OT: In almost an year we didn't add anything SMTP/POP3 related
neither improved our support for mailets (this is not a critic to you or
your cool spring module, but something our PMC should take into account)
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Bernd Fondermann <be...@googlemail.com>.
On 10/8/07, Noel J. Bergman <no...@devtech.com> wrote:
> I will go on record that I oppose a move to Spring, and have said so on
> multiple occassions. However, I do not oppose optional support for Spring.
The Phoenix deployment will live on. All the users having their own
components and whatever customizations will be supported. For new
users starting to use James there is no fundamental advantage chosing
one deployment over the other. Except if they already have Spring
components (or POJOs) they'd like to integrate with.
>
> So long as we are agreed on that, I'm +1 to on the latter.
Agreed.
>
> > As a consequence, we would be able to release a Spring-container-based
> > Server runtime besides our regular Avalon-based.
>
> I'll start another thread on Avalon.
I should have better said "Phoenix-based" instead of "Avalon-based".
We cannot live without our Excalibur bindings.
> How much does your proposed merger effect the stability of code that
> couldn't care less about Spring, e.g., the Avalon-based release?
Zero. The only thing we changed is
https://issues.apache.org/jira/browse/JAMES-803
But this is just enabling a feature in alternative FileSystem
implementations (as James/Spring has one). James/Phoenix behavior did
not change. All the checks are still in place at the more appropriate
place.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Zsombor <gz...@gmail.com>.
On 10/8/07, Stefano Bagnara <ap...@bago.org> wrote:
>
> Noel J. Bergman ha scritto:
> > I will go on record that I oppose a move to Spring, and have said so on
> > multiple occassions. However, I do not oppose optional support for
> Spring.
> >
> > So long as we are agreed on that, I'm +1 to on the latter.
>
> I think I can confirm that the support is optional.
>
> The spring module is a standalone module with dependencies on the other
> modules, but none of our other modules will depend on the spring module.
>
> >> As a consequence, we would be able to release a Spring-container-based
> >> Server runtime besides our regular Avalon-based.
> >
> > I'll start another thread on Avalon.
> >
> > How much does your proposed merger effect the stability of code that
> > couldn't care less about Spring, e.g., the Avalon-based release?
> >
> > --- Noel
>
> AFAIK nothing changed in our "main" code in order to support the spring
> integration. Bernd did a great job in writing an almost generic Avalon
> container implementation based on Spring. Furthermore "his" container
> supports the phoenix config.xml/assembly.xml out of the box.
>
> At the moment the spring deployment is still avalon-based. The only
> component replaced by Bernd is Phoenix, not Avalon.
>
> That said the spring container will also make it simpler to integrate
> non-avalon components.
>
> I bet the spring deployment will be very appreciated by that part of our
> users that are also java developers.
>
> Stefano
Me too :) I think it's much simpler to work with spring, but it's just a
personal taste/preferences.
BR,
Zsombor
Re: [VOTE] Move spring-deployment module to TRUNK
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> I will go on record that I oppose a move to Spring, and have said so on
> multiple occassions. However, I do not oppose optional support for Spring.
>
> So long as we are agreed on that, I'm +1 to on the latter.
I think I can confirm that the support is optional.
The spring module is a standalone module with dependencies on the other
modules, but none of our other modules will depend on the spring module.
>> As a consequence, we would be able to release a Spring-container-based
>> Server runtime besides our regular Avalon-based.
>
> I'll start another thread on Avalon.
>
> How much does your proposed merger effect the stability of code that
> couldn't care less about Spring, e.g., the Avalon-based release?
>
> --- Noel
AFAIK nothing changed in our "main" code in order to support the spring
integration. Bernd did a great job in writing an almost generic Avalon
container implementation based on Spring. Furthermore "his" container
supports the phoenix config.xml/assembly.xml out of the box.
At the moment the spring deployment is still avalon-based. The only
component replaced by Bernd is Phoenix, not Avalon.
That said the spring container will also make it simpler to integrate
non-avalon components.
I bet the spring deployment will be very appreciated by that part of our
users that are also java developers.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: [VOTE] Move spring-deployment module to TRUNK
Posted by "Noel J. Bergman" <no...@devtech.com>.
I will go on record that I oppose a move to Spring, and have said so on
multiple occassions. However, I do not oppose optional support for Spring.
So long as we are agreed on that, I'm +1 to on the latter.
> As a consequence, we would be able to release a Spring-container-based
> Server runtime besides our regular Avalon-based.
I'll start another thread on Avalon.
How much does your proposed merger effect the stability of code that
couldn't care less about Spring, e.g., the Avalon-based release?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On 10/8/07, Stefano Bagnara <ap...@bago.org> wrote:
>> I can't find any reference but I thought to remember I read sometimes
>> people saying that incubator can make releases but official
>> "non-incubator" ASF releases cannot depend/ship incubator products.
>
> this is a matter for each project
>
> - robert
Good to know, thank you!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/8/07, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On 10/8/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> Noel J. Bergman ha scritto:
> >>> See: http://wiki.apache.org/incubator/ComposerProposal
> >>>
> >>> --- Noel
> >> Thank you for the pointer. I read about this on the plexus list, but I
> >> think this won't affect us for a while as:
> >>
> >> 1st: we'll have to wait for it to be accepted in the incubator, promoted
> >> to TLP and release an official release.
> >
> > incubator podlings are allowed to create releases
> >
> > - robert
>
> I can't find any reference but I thought to remember I read sometimes
> people saying that incubator can make releases but official
> "non-incubator" ASF releases cannot depend/ship incubator products.
this is a matter for each project
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: The Phoenix reborn -- Plexus returning to the ASF
Posted by "Noel J. Bergman" <no...@devtech.com>.
Projects in the Incubator have one set of issues to deal with (Incubator
policies); projects that *use* them, have others.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On 10/8/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Noel J. Bergman ha scritto:
>>> See: http://wiki.apache.org/incubator/ComposerProposal
>>>
>>> --- Noel
>> Thank you for the pointer. I read about this on the plexus list, but I
>> think this won't affect us for a while as:
>>
>> 1st: we'll have to wait for it to be accepted in the incubator, promoted
>> to TLP and release an official release.
>
> incubator podlings are allowed to create releases
>
> - robert
I can't find any reference but I thought to remember I read sometimes
people saying that incubator can make releases but official
"non-incubator" ASF releases cannot depend/ship incubator products.
Is there anything true in this "memory"?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/8/07, Stefano Bagnara <ap...@bago.org> wrote:
> Noel J. Bergman ha scritto:
> > See: http://wiki.apache.org/incubator/ComposerProposal
> >
> > --- Noel
>
> Thank you for the pointer. I read about this on the plexus list, but I
> think this won't affect us for a while as:
>
> 1st: we'll have to wait for it to be accepted in the incubator, promoted
> to TLP and release an official release.
incubator podlings are allowed to create releases
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: The Phoenix reborn -- Plexus returning to the ASF
Posted by "Noel J. Bergman" <no...@devtech.com>.
> AFAIK plexus does not anymore support Avalon out of the box and I
> don't see anything about Avalon in the Composer proposal.
We'll see, and I've already raised the topic.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> See: http://wiki.apache.org/incubator/ComposerProposal
>
> --- Noel
Thank you for the pointer. I read about this on the plexus list, but I
think this won't affect us for a while as:
1st: we'll have to wait for it to be accepted in the incubator, promoted
to TLP and release an official release.
2nd: AFAIK plexus does not anymore support Avalon out of the box and I
don't see anything about Avalon in the Composer proposal.
Stefano
PS[joking]: most "Composer" committers are maven developers, don't tell
me you let the dark side of the Force flow through you! ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
The Phoenix reborn -- Plexus returning to the ASF
Posted by "Noel J. Bergman" <no...@devtech.com>.
See: http://wiki.apache.org/incubator/ComposerProposal
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org