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. I'd suggest to integrate that nuance in the decision process here. If you want an SVG representation of an individual composite document, you're better off parsing the composite XML and working off that document. If on the other hand you want an SVG representation of the 'compiled' assembly model, then you can assume correct composites with no errors, feed them to the composite 'compiler' (the composite processors Luciano is talking about), and display an SVG representation of the output. With the 'compiled' model approach you won't produce an SVG representation for A or B, the only representation which will make sense to produce is for composite C and everything it includes and uses in the above example. Circling back to Eclipse-like tools, in my experience these kinds of tools prefer to use document models (close to the document structure) for editing (assuming the concept of a document or file is exposed to the application author), as a 'compiled' model won't allow you to represent the individual documents at all (in the above example, you won't be able to visually represent and edit A or B individually). Hope this helps -- Jean-Sebastien On Mon, Jul 4, 2011 at 10:02 AM, Luciano Resende <[email protected]> wrote: > On Mon, Jul 4, 2011 at 9:44 AM, Nirmal Fernando <[email protected]> > wrote: >> >> >> On Mon, Jul 4, 2011 at 10:05 PM, Simon Laws <[email protected]> >> wrote: >>> >>> On Mon, Jul 4, 2011 at 5:30 PM, Luciano Resende <[email protected]> >>> wrote: >>> > On Mon, Jul 4, 2011 at 6:21 AM, Nirmal Fernando <[email protected]> >>> > wrote: >>> >> >>> >> Considering all the facts (such as getting exceptions when we load a >>> >> composite with errors etc.) I decided >>> >> to stick with my own code on to recognize artifacts in a composite XML >>> >> :), >>> >> but of course I could get help from >>> >> existing code. >>> >> >>> >> Current code lives at >>> >> >>> >> https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/. >>> >> >>> >> Few recognized todos : >>> >> >>> >> * References/Services that are directly linked with the composite (i.e. >>> >> not >>> >> with a component), should be addressed. >>> >> * Wire should be flexible and should not draw over other artifacts, >>> >> where >>> >> it's not necessary. >>> >> * Implementation.java elements of a component should be addressed more >>> >> carefully. >>> >> * Using "Promotion" for wiring should be addressed. >>> >> * Should check with the spec and the community whether the all >>> >> allowed/used >>> >> ways(combinations) are supported. >>> >> * Test cases >>> >> * Provides corresponding HTML output. >>> >> * Documenting layout algorithm. >>> >> >>> > >>> > Going with your own code means that you will have to mimic very >>> > complex code that handles the resolution of imports/exports, >>> > implementation.composite and other corner cases and not being able to >>> > properly handle this cases will make the tool not useful, which is the >>> > same case we see with the Eclipse STP plugin that is somewhat not >>> > useful a more real complex scenario composite. I know that sometimes >>> > it is hard to understand somebody else code, but in this case, it >>> > might be more productive to tweak the contribution processor code to >>> > be able to, based on a flag, have the expected behavior that you are >>> > expecting. >>> > >> >> I quote what I said earlier "I decided to stick with my own code on to >> recognize artifacts in a composite XML :), but of course I could get help >> from existing code.", what I meant was, I will look into the existing code >> and provide support for the missing cases. :) >> >> > > But that is the thing, it's a somewhat complex and very extensible > code, which you will now be duplicating it, and make the maintenance > of the code very expensive. Also, it might be much simpler for you to > understand how the artifact processor framework works, and tweak that > to have the expected behavior you want, then to duplicate all the > scenarios in your code. > > BTW, in the scenario that you use your own code, how are you going to > handle when someone create a new extension, will it always have to > update your code ? >>> >>> Is there anything we can do to help with understanding the existing code? >> >> I am glad if you can point me to the classes that parse a composite XML. >> >> Thanks for all the help and thoughts! >> > > At a start point, look at contribution module, and the artifact > processor pattern used, for now, you should be interested in the read > phase. The following page might be a good start for you : > > http://tuscany.apache.org/sca-java-architecture-guide.html > > particularly the following diagram > > http://tuscany.apache.org/sca-java-architecture-guide.data/contribution_overview.jpg > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/ >
