Bernd Fondermann ha scritto: > Stefano Bagnara wrote: >> 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
Disclaimer: my sentences are part of brainstorming and I'm not describing a complete solution I already analyzed and I'm supporting. That said I was thinking at it as a _real_ distribution: I may argue that I think the "end-users" of this distribution will be java developers for a while, but maybe this will change with time as we add documentations, installers, helper to manage it as windows/unix services and so on. What I wanted to notice is that if we have one step preparing all of our module jars then the phoenix deployment is simply a particular assemblage of that jars and the phoenix folder. As one of the requirement was to be able to create a customized sar then I thought we could try to solve 2 issues with one change. People wanting to use a standard JAMES will use the phoenix distribution, that do not require anything but the JVM installed and is ready to run. People wanting to customize the sar, to write some mailets (mailet sdk) or to use the spring stuff will instead download "binaries" distribution. I mean a zip file including all of the jars, some configuration file and a build.xml used to build the phoenix distribution or to build a custom sar including custom configs/jars or to build custom mailets sources placed in a specific folder. In this case the binary zip should also include the phoenix-packaging and the spring-packaging folders including jars and other files needed to create our phoenix distribution or to be able to run james using spring. The build.xml could be a specific build.xml or could be the same build.xml we used to build the modules sources but having logic to understand if there are sources or binaries and accept/reject specific targets based on this. Here ant experts suggestions will be much more useful then mine. This distribution would be much bigger than any other artifact we redistribute as it will contain all of our binaries and will include phoenix and our spring-based container (and maybe more in future). At the moment I think that it is better (for both: us and our users) to manage this as a single distributions instead of publishing more separate options. Stefano PS: About the container vs framework definitions I think there's no need to argue about this: we have different opinions and I bet we can live with it with no problems ;-) Let's concentrate on a good solution that will allow us to limit the set of distributions to manage and our users to feel comfortable with this. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
