You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Luc Maisonobe <Lu...@free.fr> on 2012/08/20 14:27:25 UTC

[all] displaying some class and sequence diagrams for our components

Hello,

As our components are mainly low level libraries, they target
developers. I wonder if we could add some basic UML diagrams for some
elements.

I know such diagrams are a pain to maintain, so I have looked at
something really simple, with the goal to only display a few core elements.

I have found plantuml <http://plantuml.sourceforge.net/index.html> to be
almost a perfect fir for this goal. It can be used from the command
line, it can be used with eclipse, it can be used with Maven (see
<https://github.com/jeluard/maven-plantuml-plugin>).

Here are some diagrams I have made for [math]:
<http://people.apache.org/~luc/plantuml-apache-commons-math/>. There are
also other diagrams I have made for Orekit, which aslo show some
sequence diagrams:
<https://www.orekit.org/static/architecture/propagation.html>.

I would like to add such diagrams to our documentation, for example by
adding a "design" directory under "src/site" for holding the .puml text
files that depict the diagrams, and generating the png images under
target/site/images. This can be done by adding the following plugin
definition to the pom, in the build section:

      <plugin>
        <groupId>com.github.jeluard</groupId>
        <artifactId>maven-plantuml-plugin</artifactId>
        <version>7876</version>
        <configuration>
          <sourceFiles>
            <directory>${basedir}</directory>
            <includes>
              <include>
                src/site/design/*.puml
              </include>
            </includes>
          </sourceFiles>
          <outputDirectory>
            ${basedir}/target/site/images/design
          </outputDirectory>
        </configuration>
        <executions>
          <execution>
            <phase>pre-site</phase>
            <goals>
              <goal>generate</goal>
            </goals>
          </execution>
        </executions>
        <dependencies>
          <dependency>
            <groupId>net.sourceforge.plantuml</groupId>
            <artifactId>plantuml</artifactId>
            <version>7930</version>
          </dependency>
        </dependencies>
      </plugin>

I don't know however if this runs everywhere, as I guess plantuml itself
has a hidden dependency to graphviz.

I have two questions. Could someone check if the maven integration runs
by itself on a pristine computer with nothing special installed (i.e.
without having graphviz pre-installed) ? What do you think about adding
such feature, either with an automatic generation of images or with the
images pre-generated by our own build tools and included (together with
their source script) in the distribution archive?

best regards,
Luc

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] displaying some class and sequence diagrams for our components

Posted by Simone Tripodi <si...@apache.org>.
Salut,

>
> Sorry, I don't think so. There are too many things in this diagram, we
> don't know what the use links are for, the complete list of enumeration
> constants is too large ...
>

you maybe missed that this tool is configurable as well[1] so you can
exclude what you're not interested.
For my assignment purpose, I had to give the complete set of info to
reviewers - lucky me you were not in the reviewers team :P

> So I understand this point of view is clearly not shared and I will
> therefore not include these diagrams in the documentation.
>

Why? Including diagrams in the doc should not find consensus in the
huge commons community - just for the record, I expressed an opinion
not an objection nor a veto - but decision should be delegated to
single component i.e. [math] people should be free to add diagrams if
they like, even if other components don't - take [pool] as a
reference, they decided to drop them recently, but they had been
included class/sequence for ages!

> best regards,
> Luc
>

best,
-Simo

[1] http://www.objectaid.com/class-diagram

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] displaying some class and sequence diagrams for our components

Posted by sebb <se...@gmail.com>.
On 22 August 2012 15:52, Phil Steitz <ph...@gmail.com> wrote:
> On 8/22/12 12:15 AM, Luc Maisonobe wrote:
>> Hi Sébastien,
>>
>> Le 21/08/2012 08:50, Sébastien Brisard a écrit :
>>> Hi Luc,
>>>
>>> 2012/8/20 Luc Maisonobe <Lu...@free.fr>
>>>> Le 20/08/2012 15:52, Simone Tripodi a écrit :
>>>>> Hi Gary!
>>>>>
>>>>>> I still like the idea! I was hoping at an automagic solution ;)
>>>>> Me too! :)
>>>> I have used several tools that were able to do such automatic diagrams
>>>> generation. All tools that support roundtrip engineering should be able
>>>> to do so. The free software tools I used are for example papyrus and
>>>> topcased. I also used non-free tools for the same purpose.
>>>>
>>>> The result is *never* good.
>>>>
>>>> Of course, the result is theoretically accurate, it represents the
>>>> current status of the code well, but it is completely useless and
>>>> unreadable. I use diagrams mainly to explain something to the readers,
>>>> to show the important stuff, to help them identify the fundamental
>>>> aspects that may be completely hidden in a maze of implementation details.
>>>>
>>>> Automatic tools are not intelligent enough to identify what is
>>>> meaningful and important and what should be discarded. If you look at
>>>> some of the diagrams in the example pages I posted, you will see
>>>> comments like "many methods not shown for clarity purposes". An
>>>> automatic tool would not do that and would display all methods equally.
>>>> Sometimes, I even suppress the method signature and show only the name,
>>>> as the signature is irrelevant to understand the concept and would
>>>> clutter the diagram.
>>>>
>>>>> The only kind of "automagic" product I found was Objectaid for
>>>>> Eclipse, but unfortunately
>>>>>
>>>>>  * it is (was, at the time of experimenting) not possible to have that
>>>>> tool included in the build;
>>>>>
>>>>>  * it is specific IDE oriented (Eclipse)
>>>>>
>>>>>  * it requires a minimum of human-interaction - automatically arranged
>>>>> layout could suck
>>>>>
>>>>>  * it is not completely free - license expires :( I tried to contact
>>>>> them to obtain a license for OSS projects only, but did not success...
>>>>>
>>>>> This is a sample[1] a made for an assignment - it looks pretty good :P
>>>> Sorry, I don't think so. There are too many things in this diagram, we
>>>> don't know what the use links are for, the complete list of enumeration
>>>> constants is too large ...
>>>>
>>>> This one of the reasons I like a small tool like plantuml. You can
>>>> specify what you want to show and what is irrelelvant for a specific
>>>> diagram. In fact, for one package or even one class, I often draw
>>>> several different diagrams that focus on different aspects in different
>>>> parts of the documentation, as these aspects are explained one after the
>>>> other, not all together.
>>>>
>>>> So I understand this point of view is clearly not shared and I will
>>>> therefore not include these diagrams in the documentation.
>>>>
>>> I wouldn't drop it that quickly! It seems to be a very interesting
>>> idea. I'm certainly not an expert on UML, but I found these diagrams
>>> useful, *when they are properly cleaned-up*. CM is a large library,
>>> and the online documentation could benefit from these diagrams. Also,
>>> it could be a useful tool for our own design discussions. So if other
>>> people in CM agrees, I'm quite willing to give a try to the tool your
>>> pointing at.
>> Then we are back to square one: can such diagrams be generated by the
>> automated maven build on all platforms, and if not should we generate
>> them by ourselves on our own development platforms and provide both the
>> source script and the generated image in the release source distribution?
>
> I like the idea of including comprehensible UML as part of the
> documentation for our components.  I am skeptical of being able to
> maintain this automagically at build time / between releases,
> however.  I will have a look at the tools mentioned in this thread
> and see if I can use them to restore the [pool] UML that I dropped
> due to laziness.  For [math], I would see it as an improvement if we
> just incorporated relevant UML into the user guide.  One thing we
> should verify is that the licensing of whatever tools we use does
> not forbid ASL licensing of generated artifacts.

And please could any diagrams include date and the software version
for which they were generated?

> Phil
>>
>> best regards,
>> Luc
>>
>>> Sébastien
>>>> best regards,
>>>> Luc
>>>>
>>>>> best,
>>>>> -Simo
>>>>>
>>>>> [1] http://simonetripodi.github.com/shs/images/http-apis.png
>>>>>
>>>>> http://people.apache.org/~simonetripodi/
>>>>> http://simonetripodi.livejournal.com/
>>>>> http://twitter.com/simonetripodi
>>>>> http://www.99soft.org/
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] displaying some class and sequence diagrams for our components

Posted by Phil Steitz <ph...@gmail.com>.
On 8/22/12 12:15 AM, Luc Maisonobe wrote:
> Hi Sébastien,
>
> Le 21/08/2012 08:50, Sébastien Brisard a écrit :
>> Hi Luc,
>>
>> 2012/8/20 Luc Maisonobe <Lu...@free.fr>
>>> Le 20/08/2012 15:52, Simone Tripodi a écrit :
>>>> Hi Gary!
>>>>
>>>>> I still like the idea! I was hoping at an automagic solution ;)
>>>> Me too! :)
>>> I have used several tools that were able to do such automatic diagrams
>>> generation. All tools that support roundtrip engineering should be able
>>> to do so. The free software tools I used are for example papyrus and
>>> topcased. I also used non-free tools for the same purpose.
>>>
>>> The result is *never* good.
>>>
>>> Of course, the result is theoretically accurate, it represents the
>>> current status of the code well, but it is completely useless and
>>> unreadable. I use diagrams mainly to explain something to the readers,
>>> to show the important stuff, to help them identify the fundamental
>>> aspects that may be completely hidden in a maze of implementation details.
>>>
>>> Automatic tools are not intelligent enough to identify what is
>>> meaningful and important and what should be discarded. If you look at
>>> some of the diagrams in the example pages I posted, you will see
>>> comments like "many methods not shown for clarity purposes". An
>>> automatic tool would not do that and would display all methods equally.
>>> Sometimes, I even suppress the method signature and show only the name,
>>> as the signature is irrelevant to understand the concept and would
>>> clutter the diagram.
>>>
>>>> The only kind of "automagic" product I found was Objectaid for
>>>> Eclipse, but unfortunately
>>>>
>>>>  * it is (was, at the time of experimenting) not possible to have that
>>>> tool included in the build;
>>>>
>>>>  * it is specific IDE oriented (Eclipse)
>>>>
>>>>  * it requires a minimum of human-interaction - automatically arranged
>>>> layout could suck
>>>>
>>>>  * it is not completely free - license expires :( I tried to contact
>>>> them to obtain a license for OSS projects only, but did not success...
>>>>
>>>> This is a sample[1] a made for an assignment - it looks pretty good :P
>>> Sorry, I don't think so. There are too many things in this diagram, we
>>> don't know what the use links are for, the complete list of enumeration
>>> constants is too large ...
>>>
>>> This one of the reasons I like a small tool like plantuml. You can
>>> specify what you want to show and what is irrelelvant for a specific
>>> diagram. In fact, for one package or even one class, I often draw
>>> several different diagrams that focus on different aspects in different
>>> parts of the documentation, as these aspects are explained one after the
>>> other, not all together.
>>>
>>> So I understand this point of view is clearly not shared and I will
>>> therefore not include these diagrams in the documentation.
>>>
>> I wouldn't drop it that quickly! It seems to be a very interesting
>> idea. I'm certainly not an expert on UML, but I found these diagrams
>> useful, *when they are properly cleaned-up*. CM is a large library,
>> and the online documentation could benefit from these diagrams. Also,
>> it could be a useful tool for our own design discussions. So if other
>> people in CM agrees, I'm quite willing to give a try to the tool your
>> pointing at.
> Then we are back to square one: can such diagrams be generated by the
> automated maven build on all platforms, and if not should we generate
> them by ourselves on our own development platforms and provide both the
> source script and the generated image in the release source distribution?

I like the idea of including comprehensible UML as part of the
documentation for our components.  I am skeptical of being able to
maintain this automagically at build time / between releases,
however.  I will have a look at the tools mentioned in this thread
and see if I can use them to restore the [pool] UML that I dropped
due to laziness.  For [math], I would see it as an improvement if we
just incorporated relevant UML into the user guide.  One thing we
should verify is that the licensing of whatever tools we use does
not forbid ASL licensing of generated artifacts.

Phil
>
> best regards,
> Luc
>
>> Sébastien
>>> best regards,
>>> Luc
>>>
>>>> best,
>>>> -Simo
>>>>
>>>> [1] http://simonetripodi.github.com/shs/images/http-apis.png
>>>>
>>>> http://people.apache.org/~simonetripodi/
>>>> http://simonetripodi.livejournal.com/
>>>> http://twitter.com/simonetripodi
>>>> http://www.99soft.org/
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] displaying some class and sequence diagrams for our components

Posted by Luc Maisonobe <Lu...@free.fr>.
Hi Sébastien,

Le 21/08/2012 08:50, Sébastien Brisard a écrit :
> Hi Luc,
> 
> 2012/8/20 Luc Maisonobe <Lu...@free.fr>
>>
>> Le 20/08/2012 15:52, Simone Tripodi a écrit :
>>> Hi Gary!
>>>
>>>> I still like the idea! I was hoping at an automagic solution ;)
>>>
>>> Me too! :)
>>
>> I have used several tools that were able to do such automatic diagrams
>> generation. All tools that support roundtrip engineering should be able
>> to do so. The free software tools I used are for example papyrus and
>> topcased. I also used non-free tools for the same purpose.
>>
>> The result is *never* good.
>>
>> Of course, the result is theoretically accurate, it represents the
>> current status of the code well, but it is completely useless and
>> unreadable. I use diagrams mainly to explain something to the readers,
>> to show the important stuff, to help them identify the fundamental
>> aspects that may be completely hidden in a maze of implementation details.
>>
>> Automatic tools are not intelligent enough to identify what is
>> meaningful and important and what should be discarded. If you look at
>> some of the diagrams in the example pages I posted, you will see
>> comments like "many methods not shown for clarity purposes". An
>> automatic tool would not do that and would display all methods equally.
>> Sometimes, I even suppress the method signature and show only the name,
>> as the signature is irrelevant to understand the concept and would
>> clutter the diagram.
>>
>>>
>>> The only kind of "automagic" product I found was Objectaid for
>>> Eclipse, but unfortunately
>>>
>>>  * it is (was, at the time of experimenting) not possible to have that
>>> tool included in the build;
>>>
>>>  * it is specific IDE oriented (Eclipse)
>>>
>>>  * it requires a minimum of human-interaction - automatically arranged
>>> layout could suck
>>>
>>>  * it is not completely free - license expires :( I tried to contact
>>> them to obtain a license for OSS projects only, but did not success...
>>>
>>> This is a sample[1] a made for an assignment - it looks pretty good :P
>>
>> Sorry, I don't think so. There are too many things in this diagram, we
>> don't know what the use links are for, the complete list of enumeration
>> constants is too large ...
>>
>> This one of the reasons I like a small tool like plantuml. You can
>> specify what you want to show and what is irrelelvant for a specific
>> diagram. In fact, for one package or even one class, I often draw
>> several different diagrams that focus on different aspects in different
>> parts of the documentation, as these aspects are explained one after the
>> other, not all together.
>>
>> So I understand this point of view is clearly not shared and I will
>> therefore not include these diagrams in the documentation.
>>
> I wouldn't drop it that quickly! It seems to be a very interesting
> idea. I'm certainly not an expert on UML, but I found these diagrams
> useful, *when they are properly cleaned-up*. CM is a large library,
> and the online documentation could benefit from these diagrams. Also,
> it could be a useful tool for our own design discussions. So if other
> people in CM agrees, I'm quite willing to give a try to the tool your
> pointing at.

Then we are back to square one: can such diagrams be generated by the
automated maven build on all platforms, and if not should we generate
them by ourselves on our own development platforms and provide both the
source script and the generated image in the release source distribution?

best regards,
Luc

> 
> Sébastien
>> best regards,
>> Luc
>>
>>>
>>> best,
>>> -Simo
>>>
>>> [1] http://simonetripodi.github.com/shs/images/http-apis.png
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] displaying some class and sequence diagrams for our components

Posted by Sébastien Brisard <se...@m4x.org>.
Hi Luc,

2012/8/20 Luc Maisonobe <Lu...@free.fr>
>
> Le 20/08/2012 15:52, Simone Tripodi a écrit :
> > Hi Gary!
> >
> >> I still like the idea! I was hoping at an automagic solution ;)
> >
> > Me too! :)
>
> I have used several tools that were able to do such automatic diagrams
> generation. All tools that support roundtrip engineering should be able
> to do so. The free software tools I used are for example papyrus and
> topcased. I also used non-free tools for the same purpose.
>
> The result is *never* good.
>
> Of course, the result is theoretically accurate, it represents the
> current status of the code well, but it is completely useless and
> unreadable. I use diagrams mainly to explain something to the readers,
> to show the important stuff, to help them identify the fundamental
> aspects that may be completely hidden in a maze of implementation details.
>
> Automatic tools are not intelligent enough to identify what is
> meaningful and important and what should be discarded. If you look at
> some of the diagrams in the example pages I posted, you will see
> comments like "many methods not shown for clarity purposes". An
> automatic tool would not do that and would display all methods equally.
> Sometimes, I even suppress the method signature and show only the name,
> as the signature is irrelevant to understand the concept and would
> clutter the diagram.
>
> >
> > The only kind of "automagic" product I found was Objectaid for
> > Eclipse, but unfortunately
> >
> >  * it is (was, at the time of experimenting) not possible to have that
> > tool included in the build;
> >
> >  * it is specific IDE oriented (Eclipse)
> >
> >  * it requires a minimum of human-interaction - automatically arranged
> > layout could suck
> >
> >  * it is not completely free - license expires :( I tried to contact
> > them to obtain a license for OSS projects only, but did not success...
> >
> > This is a sample[1] a made for an assignment - it looks pretty good :P
>
> Sorry, I don't think so. There are too many things in this diagram, we
> don't know what the use links are for, the complete list of enumeration
> constants is too large ...
>
> This one of the reasons I like a small tool like plantuml. You can
> specify what you want to show and what is irrelelvant for a specific
> diagram. In fact, for one package or even one class, I often draw
> several different diagrams that focus on different aspects in different
> parts of the documentation, as these aspects are explained one after the
> other, not all together.
>
> So I understand this point of view is clearly not shared and I will
> therefore not include these diagrams in the documentation.
>
I wouldn't drop it that quickly! It seems to be a very interesting
idea. I'm certainly not an expert on UML, but I found these diagrams
useful, *when they are properly cleaned-up*. CM is a large library,
and the online documentation could benefit from these diagrams. Also,
it could be a useful tool for our own design discussions. So if other
people in CM agrees, I'm quite willing to give a try to the tool your
pointing at.

Sébastien
> best regards,
> Luc
>
> >
> > best,
> > -Simo
> >
> > [1] http://simonetripodi.github.com/shs/images/http-apis.png
> >
> > http://people.apache.org/~simonetripodi/
> > http://simonetripodi.livejournal.com/
> > http://twitter.com/simonetripodi
> > http://www.99soft.org/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] displaying some class and sequence diagrams for our components

Posted by Luc Maisonobe <Lu...@free.fr>.
Le 20/08/2012 15:52, Simone Tripodi a écrit :
> Hi Gary!
> 
>> I still like the idea! I was hoping at an automagic solution ;)
> 
> Me too! :)

I have used several tools that were able to do such automatic diagrams
generation. All tools that support roundtrip engineering should be able
to do so. The free software tools I used are for example papyrus and
topcased. I also used non-free tools for the same purpose.

The result is *never* good.

Of course, the result is theoretically accurate, it represents the
current status of the code well, but it is completely useless and
unreadable. I use diagrams mainly to explain something to the readers,
to show the important stuff, to help them identify the fundamental
aspects that may be completely hidden in a maze of implementation details.

Automatic tools are not intelligent enough to identify what is
meaningful and important and what should be discarded. If you look at
some of the diagrams in the example pages I posted, you will see
comments like "many methods not shown for clarity purposes". An
automatic tool would not do that and would display all methods equally.
Sometimes, I even suppress the method signature and show only the name,
as the signature is irrelevant to understand the concept and would
clutter the diagram.

> 
> The only kind of "automagic" product I found was Objectaid for
> Eclipse, but unfortunately
> 
>  * it is (was, at the time of experimenting) not possible to have that
> tool included in the build;
> 
>  * it is specific IDE oriented (Eclipse)
> 
>  * it requires a minimum of human-interaction - automatically arranged
> layout could suck
> 
>  * it is not completely free - license expires :( I tried to contact
> them to obtain a license for OSS projects only, but did not success...
> 
> This is a sample[1] a made for an assignment - it looks pretty good :P

Sorry, I don't think so. There are too many things in this diagram, we
don't know what the use links are for, the complete list of enumeration
constants is too large ...

This one of the reasons I like a small tool like plantuml. You can
specify what you want to show and what is irrelelvant for a specific
diagram. In fact, for one package or even one class, I often draw
several different diagrams that focus on different aspects in different
parts of the documentation, as these aspects are explained one after the
other, not all together.

So I understand this point of view is clearly not shared and I will
therefore not include these diagrams in the documentation.

best regards,
Luc

> 
> best,
> -Simo
> 
> [1] http://simonetripodi.github.com/shs/images/http-apis.png
> 
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] displaying some class and sequence diagrams for our components

Posted by Simone Tripodi <si...@apache.org>.
Hi Gary!

> I still like the idea! I was hoping at an automagic solution ;)

Me too! :)

The only kind of "automagic" product I found was Objectaid for
Eclipse, but unfortunately

 * it is (was, at the time of experimenting) not possible to have that
tool included in the build;

 * it is specific IDE oriented (Eclipse)

 * it requires a minimum of human-interaction - automatically arranged
layout could suck

 * it is not completely free - license expires :( I tried to contact
them to obtain a license for OSS projects only, but did not success...

This is a sample[1] a made for an assignment - it looks pretty good :P

best,
-Simo

[1] http://simonetripodi.github.com/shs/images/http-apis.png

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] displaying some class and sequence diagrams for our components

Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Aug 20, 2012 at 9:17 AM, Simone Tripodi <si...@apache.org>wrote:

> > Hm, I did not realize that this was not an automatic tool. Looks like a
> > pain to maintain when you are doing refactorings...
>
> ouch :(
>

I still like the idea! I was hoping at an automagic solution ;)

Gary


> I support/like anyway the idea of adding UML diagrams on doc site - I
> requested time ago an OSS license for Objectaid [1] for Eclipse, but
> never got a reply...
>
> Maybe contacting them via members@ would be better?
>
> best,
> -Simo
>
> [1] http://www.objectaid.com/
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [all] displaying some class and sequence diagrams for our components

Posted by Simone Tripodi <si...@apache.org>.
> Hm, I did not realize that this was not an automatic tool. Looks like a
> pain to maintain when you are doing refactorings...

ouch :(

I support/like anyway the idea of adding UML diagrams on doc site - I
requested time ago an OSS license for Objectaid [1] for Eclipse, but
never got a reply...

Maybe contacting them via members@ would be better?

best,
-Simo

[1] http://www.objectaid.com/

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Re: [all] displaying some class and sequence diagrams for our components

Posted by Gary Gregory <ga...@gmail.com>.
Hm, I did not realize that this was not an automatic tool. Looks like a
pain to maintain when you are doing refactorings...

Gary

On Mon, Aug 20, 2012 at 8:41 AM, Gary Gregory <ga...@gmail.com>wrote:

> I like it!
>
> Is it slow to run?
>
> Shouldn't we add this to the parent POM?
>
> Gary
>
>
> On Mon, Aug 20, 2012 at 8:27 AM, Luc Maisonobe <Lu...@free.fr>wrote:
>
>> Hello,
>>
>> As our components are mainly low level libraries, they target
>> developers. I wonder if we could add some basic UML diagrams for some
>> elements.
>>
>> I know such diagrams are a pain to maintain, so I have looked at
>> something really simple, with the goal to only display a few core
>> elements.
>>
>> I have found plantuml <http://plantuml.sourceforge.net/index.html> to be
>> almost a perfect fir for this goal. It can be used from the command
>> line, it can be used with eclipse, it can be used with Maven (see
>> <https://github.com/jeluard/maven-plantuml-plugin>).
>>
>> Here are some diagrams I have made for [math]:
>> <http://people.apache.org/~luc/plantuml-apache-commons-math/>. There are
>> also other diagrams I have made for Orekit, which aslo show some
>> sequence diagrams:
>> <https://www.orekit.org/static/architecture/propagation.html>.
>>
>> I would like to add such diagrams to our documentation, for example by
>> adding a "design" directory under "src/site" for holding the .puml text
>> files that depict the diagrams, and generating the png images under
>> target/site/images. This can be done by adding the following plugin
>> definition to the pom, in the build section:
>>
>>       <plugin>
>>         <groupId>com.github.jeluard</groupId>
>>         <artifactId>maven-plantuml-plugin</artifactId>
>>         <version>7876</version>
>>         <configuration>
>>           <sourceFiles>
>>             <directory>${basedir}</directory>
>>             <includes>
>>               <include>
>>                 src/site/design/*.puml
>>               </include>
>>             </includes>
>>           </sourceFiles>
>>           <outputDirectory>
>>             ${basedir}/target/site/images/design
>>           </outputDirectory>
>>         </configuration>
>>         <executions>
>>           <execution>
>>             <phase>pre-site</phase>
>>             <goals>
>>               <goal>generate</goal>
>>             </goals>
>>           </execution>
>>         </executions>
>>         <dependencies>
>>           <dependency>
>>             <groupId>net.sourceforge.plantuml</groupId>
>>             <artifactId>plantuml</artifactId>
>>             <version>7930</version>
>>           </dependency>
>>         </dependencies>
>>       </plugin>
>>
>> I don't know however if this runs everywhere, as I guess plantuml itself
>> has a hidden dependency to graphviz.
>>
>> I have two questions. Could someone check if the maven integration runs
>> by itself on a pristine computer with nothing special installed (i.e.
>> without having graphviz pre-installed) ? What do you think about adding
>> such feature, either with an automatic generation of images or with the
>> images pre-generated by our own build tools and included (together with
>> their source script) in the distribution archive?
>>
>> best regards,
>> Luc
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [all] displaying some class and sequence diagrams for our components

Posted by Gary Gregory <ga...@gmail.com>.
I like it!

Is it slow to run?

Shouldn't we add this to the parent POM?

Gary

On Mon, Aug 20, 2012 at 8:27 AM, Luc Maisonobe <Lu...@free.fr>wrote:

> Hello,
>
> As our components are mainly low level libraries, they target
> developers. I wonder if we could add some basic UML diagrams for some
> elements.
>
> I know such diagrams are a pain to maintain, so I have looked at
> something really simple, with the goal to only display a few core elements.
>
> I have found plantuml <http://plantuml.sourceforge.net/index.html> to be
> almost a perfect fir for this goal. It can be used from the command
> line, it can be used with eclipse, it can be used with Maven (see
> <https://github.com/jeluard/maven-plantuml-plugin>).
>
> Here are some diagrams I have made for [math]:
> <http://people.apache.org/~luc/plantuml-apache-commons-math/>. There are
> also other diagrams I have made for Orekit, which aslo show some
> sequence diagrams:
> <https://www.orekit.org/static/architecture/propagation.html>.
>
> I would like to add such diagrams to our documentation, for example by
> adding a "design" directory under "src/site" for holding the .puml text
> files that depict the diagrams, and generating the png images under
> target/site/images. This can be done by adding the following plugin
> definition to the pom, in the build section:
>
>       <plugin>
>         <groupId>com.github.jeluard</groupId>
>         <artifactId>maven-plantuml-plugin</artifactId>
>         <version>7876</version>
>         <configuration>
>           <sourceFiles>
>             <directory>${basedir}</directory>
>             <includes>
>               <include>
>                 src/site/design/*.puml
>               </include>
>             </includes>
>           </sourceFiles>
>           <outputDirectory>
>             ${basedir}/target/site/images/design
>           </outputDirectory>
>         </configuration>
>         <executions>
>           <execution>
>             <phase>pre-site</phase>
>             <goals>
>               <goal>generate</goal>
>             </goals>
>           </execution>
>         </executions>
>         <dependencies>
>           <dependency>
>             <groupId>net.sourceforge.plantuml</groupId>
>             <artifactId>plantuml</artifactId>
>             <version>7930</version>
>           </dependency>
>         </dependencies>
>       </plugin>
>
> I don't know however if this runs everywhere, as I guess plantuml itself
> has a hidden dependency to graphviz.
>
> I have two questions. Could someone check if the maven integration runs
> by itself on a pristine computer with nothing special installed (i.e.
> without having graphviz pre-installed) ? What do you think about adding
> such feature, either with an automatic generation of images or with the
> images pre-generated by our own build tools and included (together with
> their source script) in the distribution archive?
>
> best regards,
> Luc
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [all] displaying some class and sequence diagrams for our components

Posted by Ralph Goers <ra...@dslextreme.com>.
I use http://www.websequencediagrams.com/  for most of my sequence diagrams. It won't do other UML diagrams but the sequence diagrams are incredibly easy to do.  It is also possible to just embed links to their service with your diagram text in the web site.

Ralph



On Aug 20, 2012, at 5:27 AM, Luc Maisonobe wrote:

> Hello,
> 
> As our components are mainly low level libraries, they target
> developers. I wonder if we could add some basic UML diagrams for some
> elements.
> 
> I know such diagrams are a pain to maintain, so I have looked at
> something really simple, with the goal to only display a few core elements.
> 
> I have found plantuml <http://plantuml.sourceforge.net/index.html> to be
> almost a perfect fir for this goal. It can be used from the command
> line, it can be used with eclipse, it can be used with Maven (see
> <https://github.com/jeluard/maven-plantuml-plugin>).
> 
> Here are some diagrams I have made for [math]:
> <http://people.apache.org/~luc/plantuml-apache-commons-math/>. There are
> also other diagrams I have made for Orekit, which aslo show some
> sequence diagrams:
> <https://www.orekit.org/static/architecture/propagation.html>.
> 
> I would like to add such diagrams to our documentation, for example by
> adding a "design" directory under "src/site" for holding the .puml text
> files that depict the diagrams, and generating the png images under
> target/site/images. This can be done by adding the following plugin
> definition to the pom, in the build section:
> 
>      <plugin>
>        <groupId>com.github.jeluard</groupId>
>        <artifactId>maven-plantuml-plugin</artifactId>
>        <version>7876</version>
>        <configuration>
>          <sourceFiles>
>            <directory>${basedir}</directory>
>            <includes>
>              <include>
>                src/site/design/*.puml
>              </include>
>            </includes>
>          </sourceFiles>
>          <outputDirectory>
>            ${basedir}/target/site/images/design
>          </outputDirectory>
>        </configuration>
>        <executions>
>          <execution>
>            <phase>pre-site</phase>
>            <goals>
>              <goal>generate</goal>
>            </goals>
>          </execution>
>        </executions>
>        <dependencies>
>          <dependency>
>            <groupId>net.sourceforge.plantuml</groupId>
>            <artifactId>plantuml</artifactId>
>            <version>7930</version>
>          </dependency>
>        </dependencies>
>      </plugin>
> 
> I don't know however if this runs everywhere, as I guess plantuml itself
> has a hidden dependency to graphviz.
> 
> I have two questions. Could someone check if the maven integration runs
> by itself on a pristine computer with nothing special installed (i.e.
> without having graphviz pre-installed) ? What do you think about adding
> such feature, either with an automatic generation of images or with the
> images pre-generated by our own build tools and included (together with
> their source script) in the distribution archive?
> 
> best regards,
> Luc
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>