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/
