james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Distributions [WAS: Re: ext directory [WAS Re: Imap Function]]
Date Sat, 04 Aug 2007 10:13:54 GMT
Stefano Bagnara wrote:
> 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 

It is a container, though it lacks the entry point. providing the entry 
point is trivial. it can be in a main() method, or when a servlet engine 
inits a web app. All the rest is there which makes it a container: IoC, 
factories, configuration, classloaders, contexts, ...

 > 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)

well, you _could_ write another kernel besides Spring or Phoenix.

> 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.

It will, certainly.

> 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.

Our users want easy setup, configuration, integration and extendability. 
This is where Spring could make our user's live easier.
I know that Avalon has a big bunch of capabilities. But I firmly believe 
that Spring is less invasive, easier to understand and configure, 
better documented, wider used and supported by other technologies.

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

:-) But on first start, the SAR gets expanded and only then you have 
access to crucial config files. This is really one of the biggest 
annoyances right now.

James/Phoenix setup goes like this:
1. Download dist file
2. expand (everything, but the SAR)
3. startup Phoenix (expand SAR)
4. stop Phoenix
5. edit config files etc.
6. startup Server

We now have: a cryptical, not exactly flat, directory structure with 
config files and data files spread around at  mysterious places

James/Spring would work like this:
1. Download dist file
2. expand
3. edit config files in /config
4. startup Server

This is how most software dists work nowadays. It's convenient. Less 
potential to scare users away.

> 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".

Is this "binary" dist a real distribution for end-users (what would they 
do with it?) or just a build artefact?


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

View raw message