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...@apache.org> on 2011/06/25 14:54:44 UTC
[Composite Diagram Generator] Need a suggestion
Hi All,
I need your help to decide how should Composite Diagram Generator loads
composite XML.
I can see two main options:
1) Load from the Jar file
2) Directly load the composite XML (i.e. user gives it as the input)
Thanks.
Re: [Composite Diagram Generator] Need a suggestion
Posted by Nirmal Fernando <ni...@gmail.com>.
On Fri, Aug 12, 2011 at 1:37 AM, ant elder <an...@apache.org> wrote:
> On Thu, Aug 11, 2011 at 3:52 PM, Nirmal Fernando <ni...@gmail.com>
> wrote:
> >
> >
> > On Wed, Aug 10, 2011 at 1:15 PM, ant elder <an...@apache.org> wrote:
> >>
> >> On Tue, Aug 9, 2011 at 6:55 PM, Nirmal Fernando <nirmal070125@gmail.com
> >
> >> wrote:
> >> > Hi Ant,
> >> >
> >> > On Mon, Aug 8, 2011 at 1:58 PM, ant elder <an...@gmail.com>
> wrote:
> >> >>
> >> >> Nirmal, I've just committed a module with a couple of classes that
> >> >> show how your SVG code could be used by the Tuscany Shell to draw SVG
> >> >> pictures of composites:
> >> >>
> >> >>
> >> >>
> >> >>
> https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/CompositeDiagramShellPlugin/
> >> >>
> >> >> The code is pretty simple, just one Batik class copied from their
> >> >> examples to display an SVG with Swing, and one small class for the
> >> >> Tuscany Shell command. If you check that out and from its directory
> do
> >> >> "mvn tuscany:run" it will start the Tuscany Shell and you'll see in
> >> >> the help there is a new "draw command, and entering
> >> >>
> >> >> draw CompositeDiagramShellPlugin helloworld.composite
> >> >>
> >> >> it will try to display the SVG. That doesn't quite work as the
> >> >> EntityBuilder has a problem parsing the XML. Ideally it wouldn't have
> >> >> to parse the XML but would be able to work with the Tuscany Composite
> >> >> object directly.
> >> >
> >> > Thanks for the contribution ! :)
> >> >
> >> >>
> >> >> What do you think about adding another EntityBuilder impl that works
> >> >> with the Composite object?
> >> >
> >> > I added the support to the Tuscany composite object by adding
> >> > TuscanyCompositeEntityBuilder class:
> >> >
> >> >
> https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/CompositeDiagramGeneratorUsingBatik/src/main/java/org/apache/tuscany/sca/impl/layout/TuscanyCompositeEntityBuilder.java
> >> >
> >> > And tried to run the shell command, but I think there's some problem
> >> > with
> >> > the temp file which you are creating in "DrawShellCommand" class.
> >> >
> >>
> >> Thanks Nirmal, thats looking good to me. I've updated DrawShellCommand
> >> to not use the intermediate file so it should be working now.
> >
> > Ant, I'm still getting the SVG file not found exception. Here's the
> trace:
> >
> > java.io.FileNotFoundException:
> >
> /media/798D-18B1/GSoC-2011/GSoC-2011-Nirmal/CompositeDiagramShellPlugin/file:/tmp/tmp1022936089053255799.svg
> > (No such file or directory)
> > at java.io.FileInputStream.open(Native Method)
> > at java.io.FileInputStream.<init>(FileInputStream.java:106)
> > at java.io.FileInputStream.<init>(FileInputStream.java:66)
> > at
> >
> sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
> > at
> >
> sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
> > at
> >
> org.apache.batik.util.ParsedURLData.openStreamInternal(ParsedURLData.java:547)
> > at
> > org.apache.batik.util.ParsedURLData.openStream(ParsedURLData.java:471)
> > at org.apache.batik.util.ParsedURL.openStream(ParsedURL.java:417)
> > at
> >
> org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(SAXSVGDocumentFactory.java:158)
> > at
> >
> org.apache.batik.dom.svg.SAXSVGDocumentFactory.createSVGDocument(SAXSVGDocumentFactory.java:124)
> > at
> >
> org.apache.batik.bridge.DocumentLoader.loadDocument(DocumentLoader.java:106)
> > at
> >
> org.apache.batik.swing.svg.SVGDocumentLoader.run(SVGDocumentLoader.java:84)
> >
>
> Can you try doing an svn up, mvn clean install, and then mvn
> tuscany:run to see if that fixes it? it should, the lates code in svn
> has no file code anymore.
>
>
Earlier I probably forgotten to compile the code, sorry about that!
>>
> >> I do get an error while its displaying the SVG but the image still
> >> seems to display ok -
> >>
> >> org.w3c.dom.DOMException: The "central" identifier is not a valid
> >> value for the "alignment-baseline" property.
> >>
> >> That comes from the code in CompositeArtifact.addElement and
> >> Layer.addElement setting the alignment-baseline attribute, i don't
> >> know what the issue is with that value does it mean anything to you?
> >
> > I changed it to "middle", but couldn't check whether there's an error
> still.
>
> Yes thats fixed it.
>
> >>
> >> The diagrams always have the bit at the bottom for included composites
> >> even when there aren't any included, i think it might look better if
> >> DiagramGenerator.addInclusions() did nothing when there are no
> >> included composites.
> >
> > Done! :)
> >
>
> Cool. This is looking really good i think. I've added another test
> composite to try with the shell plugin, myValue.composite, which is
> based on the one from section 5.2.1 of the Assembly spec so we can
> compare the diagram from the shell with the one in figure 5-4 in the
> spec. You can see it with the shell command "draw
> CompositeDiagramShellPlugin myValue.composite", Comparing the pictures
> i wonder how you're layout algorithm is deciding where to put the
> composite services and references? It looks like its putting them at
> the top whereas the spec images have them centered. Having them
> centered looks better to me, what do you think?
>
Done! Indeed, having them centered looks better :)
Ant, is it possible to add a test composite which has <includes> and see
whether the links are working, in the SVG viewer?
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 ant elder <an...@apache.org>.
On Thu, Aug 11, 2011 at 3:52 PM, Nirmal Fernando <ni...@gmail.com> wrote:
>
>
> On Wed, Aug 10, 2011 at 1:15 PM, ant elder <an...@apache.org> wrote:
>>
>> On Tue, Aug 9, 2011 at 6:55 PM, Nirmal Fernando <ni...@gmail.com>
>> wrote:
>> > Hi Ant,
>> >
>> > On Mon, Aug 8, 2011 at 1:58 PM, ant elder <an...@gmail.com> wrote:
>> >>
>> >> Nirmal, I've just committed a module with a couple of classes that
>> >> show how your SVG code could be used by the Tuscany Shell to draw SVG
>> >> pictures of composites:
>> >>
>> >>
>> >>
>> >> https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/CompositeDiagramShellPlugin/
>> >>
>> >> The code is pretty simple, just one Batik class copied from their
>> >> examples to display an SVG with Swing, and one small class for the
>> >> Tuscany Shell command. If you check that out and from its directory do
>> >> "mvn tuscany:run" it will start the Tuscany Shell and you'll see in
>> >> the help there is a new "draw command, and entering
>> >>
>> >> draw CompositeDiagramShellPlugin helloworld.composite
>> >>
>> >> it will try to display the SVG. That doesn't quite work as the
>> >> EntityBuilder has a problem parsing the XML. Ideally it wouldn't have
>> >> to parse the XML but would be able to work with the Tuscany Composite
>> >> object directly.
>> >
>> > Thanks for the contribution ! :)
>> >
>> >>
>> >> What do you think about adding another EntityBuilder impl that works
>> >> with the Composite object?
>> >
>> > I added the support to the Tuscany composite object by adding
>> > TuscanyCompositeEntityBuilder class:
>> >
>> > https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/CompositeDiagramGeneratorUsingBatik/src/main/java/org/apache/tuscany/sca/impl/layout/TuscanyCompositeEntityBuilder.java
>> >
>> > And tried to run the shell command, but I think there's some problem
>> > with
>> > the temp file which you are creating in "DrawShellCommand" class.
>> >
>>
>> Thanks Nirmal, thats looking good to me. I've updated DrawShellCommand
>> to not use the intermediate file so it should be working now.
>
> Ant, I'm still getting the SVG file not found exception. Here's the trace:
>
> java.io.FileNotFoundException:
> /media/798D-18B1/GSoC-2011/GSoC-2011-Nirmal/CompositeDiagramShellPlugin/file:/tmp/tmp1022936089053255799.svg
> (No such file or directory)
> at java.io.FileInputStream.open(Native Method)
> at java.io.FileInputStream.<init>(FileInputStream.java:106)
> at java.io.FileInputStream.<init>(FileInputStream.java:66)
> at
> sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
> at
> sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
> at
> org.apache.batik.util.ParsedURLData.openStreamInternal(ParsedURLData.java:547)
> at
> org.apache.batik.util.ParsedURLData.openStream(ParsedURLData.java:471)
> at org.apache.batik.util.ParsedURL.openStream(ParsedURL.java:417)
> at
> org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(SAXSVGDocumentFactory.java:158)
> at
> org.apache.batik.dom.svg.SAXSVGDocumentFactory.createSVGDocument(SAXSVGDocumentFactory.java:124)
> at
> org.apache.batik.bridge.DocumentLoader.loadDocument(DocumentLoader.java:106)
> at
> org.apache.batik.swing.svg.SVGDocumentLoader.run(SVGDocumentLoader.java:84)
>
Can you try doing an svn up, mvn clean install, and then mvn
tuscany:run to see if that fixes it? it should, the lates code in svn
has no file code anymore.
>>
>> I do get an error while its displaying the SVG but the image still
>> seems to display ok -
>>
>> org.w3c.dom.DOMException: The "central" identifier is not a valid
>> value for the "alignment-baseline" property.
>>
>> That comes from the code in CompositeArtifact.addElement and
>> Layer.addElement setting the alignment-baseline attribute, i don't
>> know what the issue is with that value does it mean anything to you?
>
> I changed it to "middle", but couldn't check whether there's an error still.
Yes thats fixed it.
>>
>> The diagrams always have the bit at the bottom for included composites
>> even when there aren't any included, i think it might look better if
>> DiagramGenerator.addInclusions() did nothing when there are no
>> included composites.
>
> Done! :)
>
Cool. This is looking really good i think. I've added another test
composite to try with the shell plugin, myValue.composite, which is
based on the one from section 5.2.1 of the Assembly spec so we can
compare the diagram from the shell with the one in figure 5-4 in the
spec. You can see it with the shell command "draw
CompositeDiagramShellPlugin myValue.composite", Comparing the pictures
i wonder how you're layout algorithm is deciding where to put the
composite services and references? It looks like its putting them at
the top whereas the spec images have them centered. Having them
centered looks better to me, what do you think?
...ant
Re: [Composite Diagram Generator] Need a suggestion
Posted by Nirmal Fernando <ni...@gmail.com>.
On Wed, Aug 10, 2011 at 1:15 PM, ant elder <an...@apache.org> wrote:
> On Tue, Aug 9, 2011 at 6:55 PM, Nirmal Fernando <ni...@gmail.com>
> wrote:
> > Hi Ant,
> >
> > On Mon, Aug 8, 2011 at 1:58 PM, ant elder <an...@gmail.com> wrote:
> >>
> >> Nirmal, I've just committed a module with a couple of classes that
> >> show how your SVG code could be used by the Tuscany Shell to draw SVG
> >> pictures of composites:
> >>
> >>
> >>
> https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/CompositeDiagramShellPlugin/
> >>
> >> The code is pretty simple, just one Batik class copied from their
> >> examples to display an SVG with Swing, and one small class for the
> >> Tuscany Shell command. If you check that out and from its directory do
> >> "mvn tuscany:run" it will start the Tuscany Shell and you'll see in
> >> the help there is a new "draw command, and entering
> >>
> >> draw CompositeDiagramShellPlugin helloworld.composite
> >>
> >> it will try to display the SVG. That doesn't quite work as the
> >> EntityBuilder has a problem parsing the XML. Ideally it wouldn't have
> >> to parse the XML but would be able to work with the Tuscany Composite
> >> object directly.
> >
> > Thanks for the contribution ! :)
> >
> >>
> >> What do you think about adding another EntityBuilder impl that works
> >> with the Composite object?
> >
> > I added the support to the Tuscany composite object by adding
> > TuscanyCompositeEntityBuilder class:
> >
> https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/CompositeDiagramGeneratorUsingBatik/src/main/java/org/apache/tuscany/sca/impl/layout/TuscanyCompositeEntityBuilder.java
> >
> > And tried to run the shell command, but I think there's some problem with
> > the temp file which you are creating in "DrawShellCommand" class.
> >
>
> Thanks Nirmal, thats looking good to me. I've updated DrawShellCommand
> to not use the intermediate file so it should be working now.
>
Ant, I'm still getting the SVG file not found exception. Here's the trace:
java.io.FileNotFoundException:
/media/798D-18B1/GSoC-2011/GSoC-2011-Nirmal/CompositeDiagramShellPlugin/file:/tmp/tmp1022936089053255799.svg
(No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:106)
at java.io.FileInputStream.<init>(FileInputStream.java:66)
at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:70)
at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:161)
at
org.apache.batik.util.ParsedURLData.openStreamInternal(ParsedURLData.java:547)
at
org.apache.batik.util.ParsedURLData.openStream(ParsedURLData.java:471)
at org.apache.batik.util.ParsedURL.openStream(ParsedURL.java:417)
at
org.apache.batik.dom.svg.SAXSVGDocumentFactory.createDocument(SAXSVGDocumentFactory.java:158)
at
org.apache.batik.dom.svg.SAXSVGDocumentFactory.createSVGDocument(SAXSVGDocumentFactory.java:124)
at
org.apache.batik.bridge.DocumentLoader.loadDocument(DocumentLoader.java:106)
at
org.apache.batik.swing.svg.SVGDocumentLoader.run(SVGDocumentLoader.java:84)
>
> I do get an error while its displaying the SVG but the image still
> seems to display ok -
>
> org.w3c.dom.DOMException: The "central" identifier is not a valid
> value for the "alignment-baseline" property.
>
> That comes from the code in CompositeArtifact.addElement and
> Layer.addElement setting the alignment-baseline attribute, i don't
> know what the issue is with that value does it mean anything to you?
>
I changed it to "middle", but couldn't check whether there's an error still.
>
> The diagrams always have the bit at the bottom for included composites
> even when there aren't any included, i think it might look better if
> DiagramGenerator.addInclusions() did nothing when there are no
> included composites.
>
Done! :)
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 ant elder <an...@apache.org>.
On Tue, Aug 9, 2011 at 6:55 PM, Nirmal Fernando <ni...@gmail.com> wrote:
> Hi Ant,
>
> On Mon, Aug 8, 2011 at 1:58 PM, ant elder <an...@gmail.com> wrote:
>>
>> Nirmal, I've just committed a module with a couple of classes that
>> show how your SVG code could be used by the Tuscany Shell to draw SVG
>> pictures of composites:
>>
>>
>> https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/CompositeDiagramShellPlugin/
>>
>> The code is pretty simple, just one Batik class copied from their
>> examples to display an SVG with Swing, and one small class for the
>> Tuscany Shell command. If you check that out and from its directory do
>> "mvn tuscany:run" it will start the Tuscany Shell and you'll see in
>> the help there is a new "draw command, and entering
>>
>> draw CompositeDiagramShellPlugin helloworld.composite
>>
>> it will try to display the SVG. That doesn't quite work as the
>> EntityBuilder has a problem parsing the XML. Ideally it wouldn't have
>> to parse the XML but would be able to work with the Tuscany Composite
>> object directly.
>
> Thanks for the contribution ! :)
>
>>
>> What do you think about adding another EntityBuilder impl that works
>> with the Composite object?
>
> I added the support to the Tuscany composite object by adding
> TuscanyCompositeEntityBuilder class:
> https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/CompositeDiagramGeneratorUsingBatik/src/main/java/org/apache/tuscany/sca/impl/layout/TuscanyCompositeEntityBuilder.java
>
> And tried to run the shell command, but I think there's some problem with
> the temp file which you are creating in "DrawShellCommand" class.
>
Thanks Nirmal, thats looking good to me. I've updated DrawShellCommand
to not use the intermediate file so it should be working now.
I do get an error while its displaying the SVG but the image still
seems to display ok -
org.w3c.dom.DOMException: The "central" identifier is not a valid
value for the "alignment-baseline" property.
That comes from the code in CompositeArtifact.addElement and
Layer.addElement setting the alignment-baseline attribute, i don't
know what the issue is with that value does it mean anything to you?
The diagrams always have the bit at the bottom for included composites
even when there aren't any included, i think it might look better if
DiagramGenerator.addInclusions() did nothing when there are no
included composites.
...ant
Re: [Composite Diagram Generator] Need a suggestion
Posted by Nirmal Fernando <ni...@gmail.com>.
Hi Ant,
On Mon, Aug 8, 2011 at 1:58 PM, ant elder <an...@gmail.com> wrote:
> Nirmal, I've just committed a module with a couple of classes that
> show how your SVG code could be used by the Tuscany Shell to draw SVG
> pictures of composites:
>
>
> https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/CompositeDiagramShellPlugin/
>
> The code is pretty simple, just one Batik class copied from their
> examples to display an SVG with Swing, and one small class for the
> Tuscany Shell command. If you check that out and from its directory do
> "mvn tuscany:run" it will start the Tuscany Shell and you'll see in
> the help there is a new "draw command, and entering
>
> draw CompositeDiagramShellPlugin helloworld.composite
>
> it will try to display the SVG. That doesn't quite work as the
> EntityBuilder has a problem parsing the XML. Ideally it wouldn't have
> to parse the XML but would be able to work with the Tuscany Composite
> object directly.
>
Thanks for the contribution ! :)
>
> What do you think about adding another EntityBuilder impl that works
> with the Composite object?
>
I added the support to the Tuscany composite object by adding
TuscanyCompositeEntityBuilder class:
https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/CompositeDiagramGeneratorUsingBatik/src/main/java/org/apache/tuscany/sca/impl/layout/TuscanyCompositeEntityBuilder.java
And tried to run the shell command, but I think there's some problem with
the temp file which you are creating in "DrawShellCommand" class.
>
> ...ant
>
> On Sat, Jun 25, 2011 at 1:54 PM, Nirmal Fernando
> <ni...@apache.org> wrote:
> > Hi All,
> >
> > I need your help to decide how should Composite Diagram Generator loads
> > composite XML.
> > I can see two main options:
> >
> > 1) Load from the Jar file
> > 2) Directly load the composite XML (i.e. user gives it as the input)
> >
> > Thanks.
> >
>
--
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 ant elder <an...@gmail.com>.
Nirmal, I've just committed a module with a couple of classes that
show how your SVG code could be used by the Tuscany Shell to draw SVG
pictures of composites:
https://svn.apache.org/repos/asf/tuscany/collaboration/GSoC-2011-Nirmal/CompositeDiagramShellPlugin/
The code is pretty simple, just one Batik class copied from their
examples to display an SVG with Swing, and one small class for the
Tuscany Shell command. If you check that out and from its directory do
"mvn tuscany:run" it will start the Tuscany Shell and you'll see in
the help there is a new "draw command, and entering
draw CompositeDiagramShellPlugin helloworld.composite
it will try to display the SVG. That doesn't quite work as the
EntityBuilder has a problem parsing the XML. Ideally it wouldn't have
to parse the XML but would be able to work with the Tuscany Composite
object directly.
What do you think about adding another EntityBuilder impl that works
with the Composite object?
...ant
On Sat, Jun 25, 2011 at 1:54 PM, Nirmal Fernando
<ni...@apache.org> wrote:
> Hi All,
>
> I need your help to decide how should Composite Diagram Generator loads
> composite XML.
> I can see two main options:
>
> 1) Load from the Jar file
> 2) Directly load the composite XML (i.e. user gives it as the input)
>
> Thanks.
>
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/
Re: [Composite Diagram Generator] Need a suggestion
Posted by Nirmal Fernando <ni...@gmail.com>.
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 ant elder <an...@gmail.com>.
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 <ni...@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?
...ant
Re: [Composite Diagram Generator] Need a suggestion
Posted by Nirmal Fernando <ni...@gmail.com>.
On Tue, Jun 28, 2011 at 9:00 PM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> On Tue, Jun 28, 2011 at 7:20 AM, Nirmal Fernando <ni...@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!
Thanks.
> ...
> --
> Jean-Sebastien
>
--
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, Jun 28, 2011 at 7:20 AM, Nirmal Fernando <ni...@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.
...
>> 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 :)
...
--
Jean-Sebastien
Re: [Composite Diagram Generator] Need a suggestion
Posted by Nirmal Fernando <ni...@gmail.com>.
Firstly many thanks to Luciano, Ant and Jean for your valuable ideas.
On Tue, Jun 28, 2011 at 8:26 AM, Jean-Sebastien Delfino <
jsdelfino@apache.org> wrote:
> On Sat, Jun 25, 2011 at 5:54 AM, Nirmal Fernando
> <ni...@apache.org> wrote:
> > Hi All,
> >
> > I need your help to decide how should Composite Diagram Generator loads
> > composite XML.
> > I can see two main options:
> >
> > 1) Load from the Jar file
> > 2) Directly load the composite XML (i.e. user gives it as the input)
> >
> > Thanks.
> >
>
> I think this calls for bigger questions:
>
> - Why will a user want to use the tool?
>
> - How will he use it?
>
> Here are some ideas, as I can think of a few use cases:
>
> A) I'm an SCA app developer and I want to use it to visualize the
> composites I'm in the middle of authoring on in my development
> environment.
>
> B) I'm an SCA app developer and I want to use it to browse a bunch of
> composites that I'm thinking about reusing.
>
> C) I'm a system administrator and I want to use it to browse the
> domain composite, the composites it includes and the composites it
> uses to check that my domain is correctly configured and wired up.
>
> D) I'm embedding Tuscany, building some tools for it, and want to
> generate these SVG diagrams programmatically.
>
> With these use cases in mind, I can see the following requirements:
>
> 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"?
> u) a command line tool that takes a directory containing a bunch of
> SCA contributions, and produces a tree of HTML + SVG linked together;
> v) a Web based tool that takes the URL of a composite document and
> serves the corresponding HTML + SVG;
> w) a Web based tool that takes the URL of an SCA domain and serves the
> corresponding HTML + SVG documents;
> x) a reusable library that takes the text of a composite and returns
> the corresponding SVG for it;
> y) a reusable library that takes a list of SCA contributions URLs and
> produces a tree of HTML + SVG linked together.
> 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?
(assuming that the validation part is done separately)
> Obviously you don't want to implement all of the above right now...
>
> To start small and simple, you could just do (x), (t) and (z), which
> would already be great!
>
> Then you could try to do (v) (x wrapped in a servlet) if you have
> time, for a nice Web browser based experience...
>
> Hope this helps
>
Thanks
> --
> Jean-Sebastien
>
--
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 Sat, Jun 25, 2011 at 5:54 AM, Nirmal Fernando
<ni...@apache.org> wrote:
> Hi All,
>
> I need your help to decide how should Composite Diagram Generator loads
> composite XML.
> I can see two main options:
>
> 1) Load from the Jar file
> 2) Directly load the composite XML (i.e. user gives it as the input)
>
> Thanks.
>
I think this calls for bigger questions:
- Why will a user want to use the tool?
- How will he use it?
Here are some ideas, as I can think of a few use cases:
A) I'm an SCA app developer and I want to use it to visualize the
composites I'm in the middle of authoring on in my development
environment.
B) I'm an SCA app developer and I want to use it to browse a bunch of
composites that I'm thinking about reusing.
C) I'm a system administrator and I want to use it to browse the
domain composite, the composites it includes and the composites it
uses to check that my domain is correctly configured and wired up.
D) I'm embedding Tuscany, building some tools for it, and want to
generate these SVG diagrams programmatically.
With these use cases in mind, I can see the following requirements:
t) a command line tool that takes the text of a composite on standard
input and prints the corresponding HTML + SVG on standard output;
u) a command line tool that takes a directory containing a bunch of
SCA contributions, and produces a tree of HTML + SVG linked together;
v) a Web based tool that takes the URL of a composite document and
serves the corresponding HTML + SVG;
w) a Web based tool that takes the URL of an SCA domain and serves the
corresponding HTML + SVG documents;
x) a reusable library that takes the text of a composite and returns
the corresponding SVG for it;
y) a reusable library that takes a list of SCA contributions URLs and
produces a tree of HTML + SVG linked together.
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 :)
Obviously you don't want to implement all of the above right now...
To start small and simple, you could just do (x), (t) and (z), which
would already be great!
Then you could try to do (v) (x wrapped in a servlet) if you have
time, for a nice Web browser based experience...
Hope this helps
--
Jean-Sebastien
Re: [Composite Diagram Generator] Need a suggestion
Posted by ant elder <an...@gmail.com>.
On Sun, Jun 26, 2011 at 6:00 AM, Nirmal Fernando
<ni...@apache.org> wrote:
>
>
> On Sat, Jun 25, 2011 at 10:02 PM, Luciano Resende <lu...@gmail.com>
> wrote:
>>
>> On Sat, Jun 25, 2011 at 5:54 AM, Nirmal Fernando
>> <ni...@apache.org> wrote:
>> > Hi All,
>> >
>> > I need your help to decide how should Composite Diagram Generator loads
>> > composite XML.
>> > I can see two main options:
>> >
>> > 1) Load from the Jar file
>> > 2) Directly load the composite XML (i.e. user gives it as the input)
>> >
>> > Thanks.
>> >
>>
>> How do you plan to run the tool that loads the composite diagram ?
>
> Currently the tool runs independently. It gets the composite XML as the
> input and
> outputs the composite diagram.
>
> To load the composite diagram Ant suggested me to use Tuscany which makes
> implementation easier.
> So the issue I have is whether to load the composite XML using jar file is
> better than directly loading composite XML (By the way, is this possible
> with Tuscany?).
>
> Highly appreciate your ideas!
>
You can load just a composite from XML using the Tuscany Deployer
which you can get from the TuscanyRuntime of NodeFactory, eg:
Deployer deployer = TuscanyRuntime.newInstance().getDeployer();
Composite composite = deployer.loadXMLDocument(new
FileReader("/some/composite.xml"));
The difference between that and the code I showed earlier using a Node
to load it from a contribution jar is that loadXMLDocument() wont do
any resolving or building so the returned model isn't complete. What
that means is that things like component types wont have been
introspected, eg if the composite contains a component which uses
<implementation.java class="sample.Helloworld" /> then you wont be
able to see what services, references, or properties is has. For your
diagram generation i'd have thought those are needed so the approach
using the contribution jars not the individual artifacts seems better.
...ant
Re: [Composite Diagram Generator] Need a suggestion
Posted by Luciano Resende <lu...@gmail.com>.
On Sat, Jun 25, 2011 at 10:00 PM, Nirmal Fernando
<ni...@apache.org> wrote:
> On Sat, Jun 25, 2011 at 10:02 PM, Luciano Resende <lu...@gmail.com>
> wrote:
>>
>> On Sat, Jun 25, 2011 at 5:54 AM, Nirmal Fernando
>> <ni...@apache.org> wrote:
>> > Hi All,
>> >
>> > I need your help to decide how should Composite Diagram Generator loads
>> > composite XML.
>> > I can see two main options:
>> >
>> > 1) Load from the Jar file
>> > 2) Directly load the composite XML (i.e. user gives it as the input)
>> >
>> > Thanks.
>> >
>>
>> How do you plan to run the tool that loads the composite diagram ?
>
> Currently the tool runs independently. It gets the composite XML as the
> input and
> outputs the composite diagram.
>
> To load the composite diagram Ant suggested me to use Tuscany which makes
> implementation easier.
> So the issue I have is whether to load the composite XML using jar file is
> better than directly loading composite XML (By the way, is this possible
> with Tuscany?).
>
> Highly appreciate your ideas!
>
>
Now that you clarified, and I looked a little in the code, I don't
understand your question :) If you have a standalone and independent
tool, what do you mean by reading the composite XML using jar ?
Also, could you elaborate on what are you going to support at the end
of the project, will I be able to load the domain composite of a
running system, or you only will be able to run it independent and by
providing the composite file ?
--
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...@apache.org>.
On Sat, Jun 25, 2011 at 10:02 PM, Luciano Resende <lu...@gmail.com>wrote:
> On Sat, Jun 25, 2011 at 5:54 AM, Nirmal Fernando
> <ni...@apache.org> wrote:
> > Hi All,
> >
> > I need your help to decide how should Composite Diagram Generator loads
> > composite XML.
> > I can see two main options:
> >
> > 1) Load from the Jar file
> > 2) Directly load the composite XML (i.e. user gives it as the input)
> >
> > Thanks.
> >
>
> How do you plan to run the tool that loads the composite diagram ?
Currently the tool runs independently. It gets the composite XML as the
input and
outputs the composite diagram.
To load the composite diagram Ant suggested me to use Tuscany which makes
implementation easier.
So the issue I have is whether to load the composite XML using jar file is
better than directly loading composite XML (By the way, is this possible
with Tuscany?).
Highly appreciate your ideas!
If
> this is part of a "Domain Manager" kind of thing, you could have some
> options like :
> a) display the diagram from the domain composite, this would display
> the aggregate view of all contributions, components, etc available on
> the domain
> b) from the information harvested from the domain, you could list the
> contributions, and it's deployable composites, and the user can click
> on it, to display the diagram for that specific composite.
>
> I had started doing some of harvesting of the domain composite and
> list of components, etc on nodeManager module in trunk
>
>
>
Thanks!
> --
> 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 Sat, Jun 25, 2011 at 5:54 AM, Nirmal Fernando
<ni...@apache.org> wrote:
> Hi All,
>
> I need your help to decide how should Composite Diagram Generator loads
> composite XML.
> I can see two main options:
>
> 1) Load from the Jar file
> 2) Directly load the composite XML (i.e. user gives it as the input)
>
> Thanks.
>
How do you plan to run the tool that loads the composite diagram ? If
this is part of a "Domain Manager" kind of thing, you could have some
options like :
a) display the diagram from the domain composite, this would display
the aggregate view of all contributions, components, etc available on
the domain
b) from the information harvested from the domain, you could list the
contributions, and it's deployable composites, and the user can click
on it, to display the diagram for that specific composite.
I had started doing some of harvesting of the domain composite and
list of components, etc on nodeManager module in trunk
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/