JBossDeveloper

I'm with John; "complex but cool" and no editing domain.xml with a running DC.

The latter is something we can change our mind on at any point; it's just a new feature in some later release. We've got plenty to do, so let's mercilessly prune this kind of thing.

Now is the time to try for the complex but cool; see what it means in practice to calculate differences. If it proves too much we can always revert to the simple approach.

OK here's a possible problem with "Complex but cool".  It's related to the "complex" part, not the "cool" part, unfortunately.

When you diff two domain.xml, is it possible that the order of operations is important?  I'm thinking (and hoping) not because we should be supportive of large atomic changes to the service environment.  But... what if I'm wrong?  How would a diff be able to shake that out?

When you diff two domain.xml, is it possible that the order of operations is important?  I'm thinking (and hoping) not because we should be supportive of large atomic changes to the service environment.  But... what if I'm wrong?  How would a diff be able to shake that out?

Renames imply order, get translated into delete/add

Jason Greene wrote:

 

When you diff two domain.xml, is it possible that the order of operations is important?  I'm thinking (and hoping) not because we should be supportive of large atomic changes to the service environment.  But... what if I'm wrong?  How would a diff be able to shake that out?

Renames imply order, get translated into delete/add

Unless you put an id on everything that can get renamed but that would suck

Also I think it goes without saying that diffing two domain models will increase the likelihood of a programming error being introduced or exposed that causes the domain to become out of sync.  That's just an inherent risk; not insurmountable.

On second thought (and some IRC chat) I think we should look at the simple case first.  As long as it is sufficient, it will be a lot less work to impl, and we can look at a diff based solution later on if time permits (year right), or if more requirements come in.

My feeling is to get the simple case working, without online editing, and only then if there is time look at updating the domain model classes to support diffing, and being implementing the extra logic required to deal with both the model differences and online editing as future feature adds.