[DISCUSS] preserving context of included composites

[kelvin goodson <kg...@thegoodsons.org.uk>]

I created TUSCANY-3374 to report the fact that we currently lose
useful context from a problem determination perspective in the first
phase of building. If I understand correctly the flattening that goes
on in this phase happens before any issues with the contribution are
detected. Coupling this with the fact that top level composites are
automatically included behind the scenes into the domain composite
(which is an implementation detail, and not a concept that the user is
aware of), and the domain composite has no name, we find that all
error messages are reported without a composite name.

Does anyone have any particular ideas on how best to solve this issue?
I think we used to build included composites before the flattening
process, in which case the context is still available, but at the time
there was an issue in wiring between components in a given
contribution, and the flattening helped address this issue.  I think
we may be in a better position now to address this. Would it be best
to hang extra context on the artefacts as we flatten, or should we
think about changing the way this build process happens?  Ideas
welcome.

Kelvin.

Re: [DISCUSS] preserving context of included composites

[Simon Laws <si...@googlemail.com>]

It was certainly the case that top level composites used to be built
independently. Chaning back to this scheme would preserve the user
defined composite name. In the distant past this did prevent
inter-composite wiring but now we have the endpoint registry this
shouldn't be an issue

However this won't fix the same problem that occurs with manually
included composites. Maybe this is less of an issue as it happens less
often and at least the user will be be aware of it when it does
happen, i.e. it isn't the result of some runtime magic.

The only alternative I can think of is, as you say, to cache the
original composite name somewhere.

Regards

Simon