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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
