You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Nirmal Fernando <ni...@gmail.com> on 2011/07/04 15:21:58 UTC
Re: [Composite Diagram Generator] Need a suggestion
On Wed, Jun 29, 2011 at 10:28 AM, ant elder <an...@gmail.com> wrote:
> On Tue, Jun 28, 2011 at 4:39 PM, Nirmal Fernando <ni...@gmail.com>
> wrote:
> >
> >
> > On Tue, Jun 28, 2011 at 9:00 PM, Jean-Sebastien Delfino
> > <js...@apache.org> wrote:
> >>
> >> On Tue, Jun 28, 2011 at 7:20 AM, Nirmal Fernando <
> nirmal070125@gmail.com>
> >> wrote:
> >> > On Tue, Jun 28, 2011 at 8:26 AM, Jean-Sebastien Delfino
> >> > <js...@apache.org> wrote:
> >> ...
> >> >> t) a command line tool that takes the text of a composite on standard
> >> >> input and prints the corresponding HTML + SVG on standard output;
> >> >
> >> > Do you mind explaining what you meant by "corresponding HTML output"?
> >> >
> >>
> >> I meant this:
> >> <html>
> >> <head>
> >> ... some CSS, Javascript etc, meta tags etc
> >> </head>
> >> <body>
> >> ... whatever you want here, a h1 tag with the name of the composite,
> >> or an href link to the composite XML for example
> >> <svg>
> >> ... your SVG composite diagram
> >> </svg>
> >> </body>
> >> </html>
> >>
> >> Most SVGs you can find on the Web are included in HTML like that as
> >> it's easier to include help, additional text, href links, meta tags,
> >> dynamic behavior with javascript etc around the SVG diagram.
> >
> > I see!
> >>
> >> ...
> >>
> >> >> z) all of the above should work with buggy, unresolved, and
> incomplete
> >> >> composites or they won't be really useful to a developer or
> >> >> administrator... just think of a Java editor that couldn't load a
> Java
> >> >> source with bugs in it... it wouldn't be so useful :)
> >> >
> >> > So, I think still I can use Tuscany runtime to load the composite XML,
> >> > am I
> >> > right?
> >>
> >> Maybe, but I'm not sure, as the runtime is not supposed to proceed
> >> with incorrect composites.
> >>
> >> Last time I checked, but that was about a year ago, I was getting
> >> exceptions preventing me to proceed and get the composite model. The
> >> error handling may have been improved since then. Better check with
> >> the other Tuscany folks working on that.
> >>
> >> > (assuming that the validation part is done separately)
> >> >
> >>
> >> I'd recommend to double check without assuming :)
> >>
> >
> > I will!
> >
>
> With the code i showed earlier it would throw exceptions when there
> are problems with contributions or composites so thats not going to
> fit in well with trying to use buggy, unresolved, or incomplete
> artifacts. It is possible to pass in a Monitor object on some of the
> calls which prevents the exception throwing and instead the problem
> information is collected in the monitor which you can then examine
> afterwards to find out about the problems so you probably could get
> something working using that approach, but I don't really know how
> well it would work as we don't presently have much in Tuscany trying
> to do that type of thing. It seems a little ambitious IMHO, if it were
> me I'd probably want to at least first get something working with
> artifacts without problems, eg take the contribution from the
> helloworld sample and draw a picture of its composite - can the SVG
> generation code you have do that yet?
>
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.
Thanks.
>
> ...ant
>
--
Best Regards,
Nirmal
C.S.Nirmal J. Fernando
Department of Computer Science & Engineering,
Faculty of Engineering,
University of Moratuwa,
Sri Lanka.
Blog: http://nirmalfdo.blogspot.com/
Re: [Composite Diagram Generator] Need a suggestion
Posted by Jean-Sebastien Delfino <js...@apache.org>.
On Tue, Aug 9, 2011 at 2:10 AM, ant elder <an...@gmail.com> wrote:
> On Tue, Aug 9, 2011 at 1:20 AM, Jean-Sebastien Delfino
> <js...@apache.org> wrote:
>> On Sat, Aug 6, 2011 at 12:27 AM, ant elder <an...@apache.org> wrote:
>>> On Fri, Aug 5, 2011 at 6:47 PM, Jean-Sebastien Delfino
>>> <js...@apache.org> wrote:
>>>> On Wed, Jul 6, 2011 at 12:34 AM, ant elder <an...@gmail.com> wrote:
>>>>> On Tue, Jul 5, 2011 at 5:15 PM, Jean-Sebastien Delfino
>>>>> <js...@apache.org> 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.
>>>>
>>>> With infinite time and resources everything is possible :)
>>>>
>>>> To draw an analogy with Java, it's a little bit like if you wanted to
>>>> write a Java editor. You could compile the Java source, then try to
>>>> have the editor work off the generated byte code, then go and tweak
>>>> the Java compiler to have the whole source embedded in the byte code,
>>>> then tweak it more to have it do that even with incomplete Java code
>>>> that wouldn't normally compile... Then you could even argue that it'd
>>>> be possible to do... with infinite time and resources :)
>>>>
>>>> I personally would never do that. I would just read and parse the Java
>>>> source, work off a model representing the Java source document and
>>>> syntax, keep it simple and go on with writing my editor without many
>>>> detours.
>>>>
>>>> That's the kind of simple approach that I was trying to describe...
>>>> But Nirmal should pick the approach that he prefers and he thinks
>>>> makes the most sense, I'll be happy with whatever works best for him
>>>> and the project.
>>>>
>>>
>>> I think the comment in your earlier email hints at where this tension
>>> is coming from -
>>>
>>> "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 don't know where that impression came from but its not the
>>> impression i get reading the project proposal -
>>> https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Develop+a+simple+tool+that+can+be+used+to+generate+composite+diagrams
>>>
>>> It should "Develop a _simple_ tool ...", my emphasis on simple, ... that can
>>> "1) Help to document Tuscany's tutorials and samples.
>>> 2) Integrate with the SCA domain manager to visualize the SCA domain
>>> (contributions, composites, nodes etc)."
>>
>> ...
>>
>> So we're just getting different impressions. That happens :)
>>
>> IMO 'help document tutorials and samples' is in line with 'give you a
>> view of the composites as they are authored...' and 'integrate with
>> the SCA domain manager' is also well in line with 'give you a view of
>> the composites as they are ... configured'.
>>
>> I think it's better to have the visualization that documents a
>> composite closer to the composite document as it was
>> authored/configured composite than the result of its compilation (and
>> again you could apply the same principle to Java or any other
>> programming or composition language). I also think it's simpler to do
>> it this way, as I've tried to explain in the last few emails.
>>
>> You don't think the same way, and that's OK with me, plus I'm not sure
>> I'll be able to convince you otherwise anyway.
>>
>> I'd be interested in Nirmal's opinion too. He has already spent quite
>> a bit of time on the subject and made really good progress, so like I
>> already said, I think he should pick the approach that he thinks works
>> best for his project.
>>
>
> The thing is with open source and Apache projects in particular in
> order to get code that lasts you need to collaborate, find consensus
> and foster others helping with your code. Of course this project could
> just focus solely on the approach you've suggested, maybe it would
> take off and be successful though we don't really have many
> environments yet where it will get used much like that and as you
> comment in an earlier email its an approach that is "...probably not
> going to be very popular with other people in the Tuscany project or
> the SCA spec group" so the chances of it being maintained after GSoC
> aren't great.
I suggested 4 approaches to a related question that Nirmal had about
Java components, and had the honesty to mention that one approach,
option (d) was not going to be very popular (even though I thought it
was technically the best one). Please, at least have the honesty to
not take that out of context and make us believe that this was
"solely" the "approach I've suggested", to suit your argument here, as
I actually recommended to look into the other approaches first.
Here's the email you referenced:
http://marc.info/?l=tuscany-dev&m=131256472227802&w=2
> Adding support for both approaches looks to me like it
> wouldn't be hard - there just needs to be one more class added for an
> EntityBuilder impl that can work off the Tuscany Composite objects
> instead of raw XML. With that done we could then use this with things
> like the Tuscany Shell and all the samples and demos which would make
> this project immediately useful and much more likely to maintained and
> enhanced after GSoC.
Sure, if you're volunteering to push the approach you prefer and if
that's your idea of consensus :) I don't have any problem with that.
I'm actually feeling pretty happy about it, as I'm sure it'll be great
and many people in the project will be happy to maintain it!
Let me know if I can help.
--
Jean-Sebastien
Re: [Composite Diagram Generator] Need a suggestion
Posted by ant elder <an...@gmail.com>.
On Tue, Aug 9, 2011 at 1:20 AM, Jean-Sebastien Delfino
<js...@apache.org> wrote:
> On Sat, Aug 6, 2011 at 12:27 AM, ant elder <an...@apache.org> wrote:
>> On Fri, Aug 5, 2011 at 6:47 PM, Jean-Sebastien Delfino
>> <js...@apache.org> wrote:
>>> On Wed, Jul 6, 2011 at 12:34 AM, ant elder <an...@gmail.com> wrote:
>>>> On Tue, Jul 5, 2011 at 5:15 PM, Jean-Sebastien Delfino
>>>> <js...@apache.org> 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.
>>>
>>> With infinite time and resources everything is possible :)
>>>
>>> To draw an analogy with Java, it's a little bit like if you wanted to
>>> write a Java editor. You could compile the Java source, then try to
>>> have the editor work off the generated byte code, then go and tweak
>>> the Java compiler to have the whole source embedded in the byte code,
>>> then tweak it more to have it do that even with incomplete Java code
>>> that wouldn't normally compile... Then you could even argue that it'd
>>> be possible to do... with infinite time and resources :)
>>>
>>> I personally would never do that. I would just read and parse the Java
>>> source, work off a model representing the Java source document and
>>> syntax, keep it simple and go on with writing my editor without many
>>> detours.
>>>
>>> That's the kind of simple approach that I was trying to describe...
>>> But Nirmal should pick the approach that he prefers and he thinks
>>> makes the most sense, I'll be happy with whatever works best for him
>>> and the project.
>>>
>>
>> I think the comment in your earlier email hints at where this tension
>> is coming from -
>>
>> "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 don't know where that impression came from but its not the
>> impression i get reading the project proposal -
>> https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Develop+a+simple+tool+that+can+be+used+to+generate+composite+diagrams
>>
>> It should "Develop a _simple_ tool ...", my emphasis on simple, ... that can
>> "1) Help to document Tuscany's tutorials and samples.
>> 2) Integrate with the SCA domain manager to visualize the SCA domain
>> (contributions, composites, nodes etc)."
>
> ...
>
> So we're just getting different impressions. That happens :)
>
> IMO 'help document tutorials and samples' is in line with 'give you a
> view of the composites as they are authored...' and 'integrate with
> the SCA domain manager' is also well in line with 'give you a view of
> the composites as they are ... configured'.
>
> I think it's better to have the visualization that documents a
> composite closer to the composite document as it was
> authored/configured composite than the result of its compilation (and
> again you could apply the same principle to Java or any other
> programming or composition language). I also think it's simpler to do
> it this way, as I've tried to explain in the last few emails.
>
> You don't think the same way, and that's OK with me, plus I'm not sure
> I'll be able to convince you otherwise anyway.
>
> I'd be interested in Nirmal's opinion too. He has already spent quite
> a bit of time on the subject and made really good progress, so like I
> already said, I think he should pick the approach that he thinks works
> best for his project.
>
The thing is with open source and Apache projects in particular in
order to get code that lasts you need to collaborate, find consensus
and foster others helping with your code. Of course this project could
just focus solely on the approach you've suggested, maybe it would
take off and be successful though we don't really have many
environments yet where it will get used much like that and as you
comment in an earlier email its an approach that is "...probably not
going to be very popular with other people in the Tuscany project or
the SCA spec group" so the chances of it being maintained after GSoC
aren't great. Adding support for both approaches looks to me like it
wouldn't be hard - there just needs to be one more class added for an
EntityBuilder impl that can work off the Tuscany Composite objects
instead of raw XML. With that done we could then use this with things
like the Tuscany Shell and all the samples and demos which would make
this project immediately useful and much more likely to maintained and
enhanced after GSoC.
...ant
Re: [Composite Diagram Generator] Need a suggestion
Posted by Jean-Sebastien Delfino <js...@apache.org>.
On Sat, Aug 6, 2011 at 12:27 AM, ant elder <an...@apache.org> wrote:
> On Fri, Aug 5, 2011 at 6:47 PM, Jean-Sebastien Delfino
> <js...@apache.org> wrote:
>> On Wed, Jul 6, 2011 at 12:34 AM, ant elder <an...@gmail.com> wrote:
>>> On Tue, Jul 5, 2011 at 5:15 PM, Jean-Sebastien Delfino
>>> <js...@apache.org> 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.
>>
>> With infinite time and resources everything is possible :)
>>
>> To draw an analogy with Java, it's a little bit like if you wanted to
>> write a Java editor. You could compile the Java source, then try to
>> have the editor work off the generated byte code, then go and tweak
>> the Java compiler to have the whole source embedded in the byte code,
>> then tweak it more to have it do that even with incomplete Java code
>> that wouldn't normally compile... Then you could even argue that it'd
>> be possible to do... with infinite time and resources :)
>>
>> I personally would never do that. I would just read and parse the Java
>> source, work off a model representing the Java source document and
>> syntax, keep it simple and go on with writing my editor without many
>> detours.
>>
>> That's the kind of simple approach that I was trying to describe...
>> But Nirmal should pick the approach that he prefers and he thinks
>> makes the most sense, I'll be happy with whatever works best for him
>> and the project.
>>
>
> I think the comment in your earlier email hints at where this tension
> is coming from -
>
> "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 don't know where that impression came from but its not the
> impression i get reading the project proposal -
> https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Develop+a+simple+tool+that+can+be+used+to+generate+composite+diagrams
>
> It should "Develop a _simple_ tool ...", my emphasis on simple, ... that can
> "1) Help to document Tuscany's tutorials and samples.
> 2) Integrate with the SCA domain manager to visualize the SCA domain
> (contributions, composites, nodes etc)."
...
So we're just getting different impressions. That happens :)
IMO 'help document tutorials and samples' is in line with 'give you a
view of the composites as they are authored...' and 'integrate with
the SCA domain manager' is also well in line with 'give you a view of
the composites as they are ... configured'.
I think it's better to have the visualization that documents a
composite closer to the composite document as it was
authored/configured composite than the result of its compilation (and
again you could apply the same principle to Java or any other
programming or composition language). I also think it's simpler to do
it this way, as I've tried to explain in the last few emails.
You don't think the same way, and that's OK with me, plus I'm not sure
I'll be able to convince you otherwise anyway.
I'd be interested in Nirmal's opinion too. He has already spent quite
a bit of time on the subject and made really good progress, so like I
already said, I think he should pick the approach that he thinks works
best for his project.
--
Jean-Sebastien
Re: [Composite Diagram Generator] Need a suggestion
Posted by ant elder <an...@apache.org>.
On Fri, Aug 5, 2011 at 6:47 PM, Jean-Sebastien Delfino
<js...@apache.org> wrote:
> On Wed, Jul 6, 2011 at 12:34 AM, ant elder <an...@gmail.com> wrote:
>> On Tue, Jul 5, 2011 at 5:15 PM, Jean-Sebastien Delfino
>> <js...@apache.org> 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.
>
> With infinite time and resources everything is possible :)
>
> To draw an analogy with Java, it's a little bit like if you wanted to
> write a Java editor. You could compile the Java source, then try to
> have the editor work off the generated byte code, then go and tweak
> the Java compiler to have the whole source embedded in the byte code,
> then tweak it more to have it do that even with incomplete Java code
> that wouldn't normally compile... Then you could even argue that it'd
> be possible to do... with infinite time and resources :)
>
> I personally would never do that. I would just read and parse the Java
> source, work off a model representing the Java source document and
> syntax, keep it simple and go on with writing my editor without many
> detours.
>
> That's the kind of simple approach that I was trying to describe...
> But Nirmal should pick the approach that he prefers and he thinks
> makes the most sense, I'll be happy with whatever works best for him
> and the project.
>
I think the comment in your earlier email hints at where this tension
is coming from -
"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 don't know where that impression came from but its not the
impression i get reading the project proposal -
https://cwiki.apache.org/confluence/display/TUSCANYWIKI/Develop+a+simple+tool+that+can+be+used+to+generate+composite+diagrams
It should "Develop a _simple_ tool ...", my emphasis on simple, ... that can
"1) Help to document Tuscany's tutorials and samples.
2) Integrate with the SCA domain manager to visualize the SCA domain
(contributions, composites, nodes etc)."
Which makes it sound to me like it _would_ work on the compiled model.
Tto continue with the Java analogy, its not so much a Java editor its
more like a tool to generate a class diagram for a Java application.
Most of the tools diagram generating code would be the same either way
so how about having it support both approaches? We're starting to
finish the doc on the samples now so it would be great if this tool
could help create diagrams for them. What i'd like is something like a
"diagram" command plugin for the Tuscany Shell so that you can show
the diagrams at the Shell command prompt. That should be pretty easy
to do and a lot of the diagram generating code looks like its already
capable of that type of thing so it wouldn't be too much work.
...ant
Re: [Composite Diagram Generator] Need a suggestion
Posted by Jean-Sebastien Delfino <js...@apache.org>.
On Wed, Jul 6, 2011 at 12:34 AM, ant elder <an...@gmail.com> wrote:
> On Tue, Jul 5, 2011 at 5:15 PM, Jean-Sebastien Delfino
> <js...@apache.org> 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.
With infinite time and resources everything is possible :)
To draw an analogy with Java, it's a little bit like if you wanted to
write a Java editor. You could compile the Java source, then try to
have the editor work off the generated byte code, then go and tweak
the Java compiler to have the whole source embedded in the byte code,
then tweak it more to have it do that even with incomplete Java code
that wouldn't normally compile... Then you could even argue that it'd
be possible to do... with infinite time and resources :)
I personally would never do that. I would just read and parse the Java
source, work off a model representing the Java source document and
syntax, keep it simple and go on with writing my editor without many
detours.
That's the kind of simple approach that I was trying to describe...
But Nirmal should pick the approach that he prefers and he thinks
makes the most sense, I'll be happy with whatever works best for him
and the project.
--
Jean-Sebastien
Re: [Composite Diagram Generator] Need a suggestion
Posted by ant elder <an...@gmail.com>.
On Tue, Jul 5, 2011 at 5:15 PM, Jean-Sebastien Delfino
<js...@apache.org> 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
Re: [Composite Diagram Generator] Need a suggestion
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <lu...@gmail.com> wrote:
> On Mon, Jul 4, 2011 at 9:44 AM, Nirmal Fernando <ni...@gmail.com> wrote:
>>
>>
>> On Mon, Jul 4, 2011 at 10:05 PM, Simon Laws <si...@googlemail.com>
>> wrote:
>>>
>>> On Mon, Jul 4, 2011 at 5:30 PM, Luciano Resende <lu...@gmail.com>
>>> wrote:
>>> > On Mon, Jul 4, 2011 at 6:21 AM, Nirmal Fernando <ni...@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.
>>> >
>>
>> 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/
>
Re: [Composite Diagram Generator] Need a suggestion
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Jul 4, 2011 at 9:44 AM, Nirmal Fernando <ni...@gmail.com> wrote:
>
>
> On Mon, Jul 4, 2011 at 10:05 PM, Simon Laws <si...@googlemail.com>
> wrote:
>>
>> On Mon, Jul 4, 2011 at 5:30 PM, Luciano Resende <lu...@gmail.com>
>> wrote:
>> > On Mon, Jul 4, 2011 at 6:21 AM, Nirmal Fernando <ni...@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.
>> >
>
> 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/
Re: [Composite Diagram Generator] Need a suggestion
Posted by Nirmal Fernando <ni...@gmail.com>.
On Mon, Jul 4, 2011 at 10:05 PM, Simon Laws <si...@googlemail.com>wrote:
> On Mon, Jul 4, 2011 at 5:30 PM, Luciano Resende <lu...@gmail.com>
> wrote:
> > On Mon, Jul 4, 2011 at 6:21 AM, Nirmal Fernando <ni...@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.
> >
>
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. :)
> --
> > Luciano Resende
> > http://people.apache.org/~lresende
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
>
> 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!
>
> Simon
>
> --
> Apache Tuscany committer: tuscany.apache.org
> Co-author of a book about Tuscany and SCA: tuscanyinaction.com
>
--
Best Regards,
Nirmal
C.S.Nirmal J. Fernando
Department of Computer Science & Engineering,
Faculty of Engineering,
University of Moratuwa,
Sri Lanka.
Blog: http://nirmalfdo.blogspot.com/
Re: [Composite Diagram Generator] Need a suggestion
Posted by Simon Laws <si...@googlemail.com>.
On Mon, Jul 4, 2011 at 5:30 PM, Luciano Resende <lu...@gmail.com> wrote:
> On Mon, Jul 4, 2011 at 6:21 AM, Nirmal Fernando <ni...@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/
>
Is there anything we can do to help with understanding the existing code?
Simon
--
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com
Re: [Composite Diagram Generator] Need a suggestion
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Jul 4, 2011 at 6:21 AM, Nirmal Fernando <ni...@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/