I think a developer centric deployment model is fine as long as we articulate how the exploded-archive should be built ( i.e. all WSDL, Schema, etc ... dependencies should be copied first and then the .bpel file ) and fail gracefully when artifacts can't be found. Is this what you had in mind?
Lance On 5/3/06, Alex Boisvert <[EMAIL PROTECTED]> wrote:
As a developer, I'm a big fan of the exploded-archive format -- which is effectively an oximoron for no deployment archive -- where individual files are just moved or copied in a deployment area on the file system. I think this approach reduces the need for deployment tooling, reduces deployment times (faster test cycles) and reduces indirections, meaning that I know exactly what's deployed instead of guessing what's been put in the archive. It would be nice if the engine supported this kind of straight-through deployment in addition to the heavier archive deployment alex Matthieu Riou wrote: > Hi, > > Lance mentioned before the need to agree on a deployment format for > Ode, in short to answer to the question "what will I deploy in Ode?". > Note that the question is 'what', not 'how' (yet). To start the debate > I'll just drop some of the requirements I'd have, to see what you guys > think. > > First, we could support two types of deployment unit, just like any > J2EE app server does: > > 1. A raw format with no prior compilation, generation whatsoever. The > magic happens on deployment. > 2. A compiled, validated, ready to use format. Upon deployment this > thing is just opened, read and we're ready to go. > > For this first format, I think we just need a self containing archive, > including not only the process representation but also wsdl, xsl, > deployment descriptor, whatever... End of requirements. > > The second format should be compiled and validated. So most (if not > all) possible errors in the original bpel description, the wsld or > anything else should be detected during the step that produces this > deployment unit. The compiled version of the process should be as > close as possible to the definition model used at runtime (something > like a pre-processed object tree). > > This two format wouldn't be exclusive, it's just 2 steps in the > lifetime of our deployed package. This 2 steps can happen all at one > time (1 -> 2 -> running) or one after another (1 -> 2 // 2 -> > running). > > Thoughts? Comments? Criticisms? Flames? > > Matthieu.
