Stefano Bagnara wrote:
Robert Burrell Donkin ha scritto:
On 8/1/07, Stefano Bagnara <[EMAIL PROTECTED]> 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?
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
