On Mon, Jul 4, 2011 at 6:21 AM, Nirmal Fernando <nirmal070...@gmail.com> 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. -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
