james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: ext directory [WAS Re: Imap Function]
Date Thu, 02 Aug 2007 13:14:43 GMT
Robert Burrell Donkin ha scritto:
> On 8/1/07, Stefano Bagnara <apache@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
> 
> <snip>
> 
>>>> In fact it does not build anything from source: it only has to take the
>>>> original SAR, replace the config.xml and add some library.
>>>>
>>>> Maybe the tool (another ant script) would also be useful to people
>>>> downloading the binary distribution (well, in fact it is only a zip
>>>> file, but I saw some user has problems working with it).
>>> i agree that a SAR manipulation tool would be useful for the binary
>>> distribution. IIRC pheonix ships an ant task for this. would need to
>>> think about whether documentation on customisation would be better
>>> than an actual script.
>>>
>>> - robert
>> Maybe it's time to split the sar generation from the phoenix-deployment.
>> This way we could have a module building the sar and another module that
>> takes the sar and place it in the phoenix distribution to create a
>> binary build. The ant script used for this last action could be almost
>> the same used by the binary distribution to create custom sar.
>> I don't know if the api-library-function-deployment layers are enough to
>> do that.
> 
> i suppose the bigger question is how to approach binary distributions
> once JAMES supports multiple containers: do we issue an distribution
> per container or one distribution containing multiple artifacts?
> 
> - robert

Interesting question.

I think that, at the moment, the spring deployment is more developer
oriented than user oriented.

Spring is not a container but a framework and we can compare it to
avalon and not to phoenix. Bernd wrote a simple startup class and not a
full "server" kernel for the spring based solution. We could have
written a simple startup class also for the avalon components (in fact
what Bernd wrote is an avalon-to-spring wrapper and a simple container
for spring, so it is in the end a simple container for avalon applications)

So, currently, I think that the spring deployment option is more about
downloading the right jars and follow documentation for specific use
cases, but the official deployment will remain phoenix for a while.
Developers will probably want to look at the startup method to
understand how to invoke it within their own application and how to get
references to our components so to be able to interact with them.

In the phoenix deployment we bundle everything in a sar, while a spring
distribution would need that jars/xmls exploded.

As a "next step" we could have a "raw" binary distribution including all
of our modules jars and configurations files and the deployment options.
In addition to this we can then provide the current phenix distribution
starting from this one.

This way we have a "binaries" distribution and a "phoenix-deployment".

The more the components will be de-avalonized the more likely we'll move
to different configuration/management options, too.

IMHO in the long terms we will have to keep choosing a single container
for our main distribution while trying to keep core components easy to
be ported to different environments/containers.

I would avoid having an osgi distribution, a spring distribution, a
phoenix distribution, a j2ee distribution a plexus distribution and so
on. This would mean having to test too much environments, having to
provide documentations and support for each one of them: IMHO we won't
be able to afford this in the "near" (1-2 years) future.

Btw, in the end, most of this depends on the community reaction to the
spring support: let's see what they ask and what they do with that
module and we'll know what is better to do in the next release.

Stefano


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


Mime
View raw message