On Wed, May 7, 2008 at 8:10 AM, Tammo van Lessen <[EMAIL PROTECTED]> wrote:
> Hi guys, > > while thinking about how to model an deploy.xml editor, I stumbled upon > some elements in the schema I don't really understand. > > a) What is the scenario for deploying a retired process? Isn't that > handled by process versioning? > That was in the old sense of retiring, when retiring was actually what we call deactivating now. The idea was that you could deploy processes without wanting them to be active in the engine, I'm not aware of anybody wanting this feature so I wouldn't mind removing it (especially now that we have dehydration). > > a1) I'm a correctly assuming that <active> and <retired> model a tri-state > attribute? > I have hard time figuring out what a non-retired non-active state would be. > > b) What is the <type>-element good for? What is the difference to <name>? > IMO, premature abstraction. Internally the type is the process name and differs from the id (where the version is compounded). I'm not sure renaming (or changing the type of if you prefer) the process in the descriptor is a feature we want/need. If we do, we should make it a bit more explicit. And if nobody cares (and I certainly don't), we should remove this element. > > and finally I'm wondering whether > DeploymentUnitDir.prepareCompileProperties(File) should really skip > processing custom properties if the bpelFileName is not specified or rather > should scan for a matching entry (based on the process' qname) in the > process list? > IIRC (and maybe I don't) at this stage the process hasn't been compiled yet. So it's a chicken-and-egg problem. Matthieu > > Thanks, > Tammo >
