...snip > If we are going for consistency then I think 1-1 is not an option > because of runtime situations that don't fit this pattern. I think > we are likely to need a mixture of 1-2 and 1-3 depending on the code > execution path.
So the third category of confusion should of course have been 3 Where are the errors being reported 3-1 read 3-2 resolve 3-3 build 3-4 activate 3-5 start 3-6 runtime 3-7 stop I think we have been considering 3-1 to 3-5 and 3-7 as one and distinct from 3-6. At the moment I believe we currently only use the monitor in 3-1 to 3-3. I think it will be > a big step backwards in usability if only one error in the static > artifacts can be detected at a time. I would happily replace a list of several unclear error s for one clear error. but maybe we just have to agree to disagree on this. To move forward it not going to worry me if we deal with this once we have the context question under control. > > 2-2 would be far too much work. 2-4 doesn't have sense to me as we > should always be producing context when we have addressed issue 1. I agree and raised this specifically as there was a suggestion previously on the thread that the lack of context was a valid reason for not performing subsequent processing which seemed a bit arbitrary to me. Simon
