On Tue, Jul 5, 2011 at 5:15 PM, Jean-Sebastien Delfino <[email protected]> wrote: > A few thoughts: > > I was under the impression that the SVG diagram generator would give > you a view of the composites as they are authored or configured, and > not necessarily a view of the reduced and 'compiled' composition model > resulting from their assembly processing > > (I'm using the term 'compile' in the general sense here, not to > generate machine code but to collect and compose artifacts into a form > optimized form for a particular usage scenario, i.e. in Tuscany, an > assembly model optimized for running an SCA composite application). > > To take an example, if a composite A included another composite B or > used B as an implementation, and was itself included in another > composite C, I imagined an SVG representation for A with a link to B's > SVG representation, instead of an SVG representation of the reduced > and 'compiled' combination of A, B and C. >
Are you sure that isn't possible to do from the Tuscany 'compiled' model? I think it should be, the information isn't thrown away and the model objects have references to all the necessary artifacts. If it turns out there is something getting lost then we could just fix that so that the info is maintained. Anyway either way, isn't the bulk of this project work the code to layout and draw the diagrams? The code for the project already has classes to represent composites, components, services etc which are what the layout and drawing finctions use, so its just a question of how those get populated. Isn't it not so much work to support doing that from both the Tuscany runtime model objects and also some new code that can handle loading buggy, unresolved, or incomplete artifacts? ...ant
