You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@streams.apache.org by sblackmon <sb...@apache.org> on 2016/10/23 15:33:22 UTC
Better managing website SVGs
Hello,
In the past I’ve been generating the SVGs (from DOT/graphviz) that are part of the website as part of the publishing process as described here:
http://streams.incubator.apache.org/site/0.4-incubating-SNAPSHOT/streams-master/website.html
This is preferable to checking in the SVGs in that it doesn’t require every developer to remember to regenerate the SVG every time any DOT file changes.
The downside is that builds.apache.org ubuntu hosts don’t have dot installed so I don’t see how this step can be hooked up to CI.
Does anyone know of a way to get the dot package installed on those hosts when our builds run? Or is it feasible to request hosts with additional packaged installed to make this possible? Or any other workable ideas?
If not, I reluctantly propose that anyone changing a dot file will need to regenerate and check in the new SVG - so that we can run scmpublish from jenkins and omit this tedious manual step on each website change.
Steve
Re: Better managing website SVGs
Posted by sblackmon <sb...@apache.org>.
You can browse through all of the diagrams migrated into confluence here -
https://cwiki.apache.org/confluence/display/STREAMS/Graphviz+Diagrams
On November 25, 2016 at 3:22:47 PM, sblackmon (sblackmon@apache.org) wrote:
Following up about how we manage DOT/SVG files:
I discovered this morning that cwiki.apache.org has a plugin for managing graphviz files.
https://cwiki.apache.org/confluence/display/STREAMS/Graphviz+Diagrams
After some experimentation, I think I’ve confirmed that the following will work:
a) migrate dot files out of our source control repos and into confluence
b) place them in a page hierarchy aligned with our source hierarchy
c) manage their content from here on out in confluence
d) embed them in the web page as we currently do, using links such as https://cwiki.apache.org/confluence/download/attachments/66854246/integration.svg.svg?api=v2
e) the SVG representation of each diagram gets created by the confluence plugin and exposed to the web by confluence CMS.
To the degree we want older versions of the diagrams to remain accessible, we can store their SVGs in the confluence CMS in perpetuity.
I’ve opened STREAMS-462 to do the above, and to add a section to the website describing how to alter embedded diagrams.
Steve
On October 23, 2016 at 10:33:26 AM, sblackmon (sblackmon@apache.org) wrote:
Hello,
In the past I’ve been generating the SVGs (from DOT/graphviz) that are part of the website as part of the publishing process as described here:
http://streams.incubator.apache.org/site/0.4-incubating-SNAPSHOT/streams-master/website.html
This is preferable to checking in the SVGs in that it doesn’t require every developer to remember to regenerate the SVG every time any DOT file changes.
The downside is that builds.apache.org ubuntu hosts don’t have dot installed so I don’t see how this step can be hooked up to CI.
Does anyone know of a way to get the dot package installed on those hosts when our builds run? Or is it feasible to request hosts with additional packaged installed to make this possible? Or any other workable ideas?
If not, I reluctantly propose that anyone changing a dot file will need to regenerate and check in the new SVG - so that we can run scmpublish from jenkins and omit this tedious manual step on each website change.
Steve
Re: Better managing website SVGs
Posted by sblackmon <sb...@apache.org>.
Following up about how we manage DOT/SVG files:
I discovered this morning that cwiki.apache.org has a plugin for managing graphviz files.
https://cwiki.apache.org/confluence/display/STREAMS/Graphviz+Diagrams
After some experimentation, I think I’ve confirmed that the following will work:
a) migrate dot files out of our source control repos and into confluence
b) place them in a page hierarchy aligned with our source hierarchy
c) manage their content from here on out in confluence
d) embed them in the web page as we currently do, using links such as https://cwiki.apache.org/confluence/download/attachments/66854246/integration.svg.svg?api=v2
e) the SVG representation of each diagram gets created by the confluence plugin and exposed to the web by confluence CMS.
To the degree we want older versions of the diagrams to remain accessible, we can store their SVGs in the confluence CMS in perpetuity.
I’ve opened STREAMS-462 to do the above, and to add a section to the website describing how to alter embedded diagrams.
Steve
On October 23, 2016 at 10:33:26 AM, sblackmon (sblackmon@apache.org) wrote:
Hello,
In the past I’ve been generating the SVGs (from DOT/graphviz) that are part of the website as part of the publishing process as described here:
http://streams.incubator.apache.org/site/0.4-incubating-SNAPSHOT/streams-master/website.html
This is preferable to checking in the SVGs in that it doesn’t require every developer to remember to regenerate the SVG every time any DOT file changes.
The downside is that builds.apache.org ubuntu hosts don’t have dot installed so I don’t see how this step can be hooked up to CI.
Does anyone know of a way to get the dot package installed on those hosts when our builds run? Or is it feasible to request hosts with additional packaged installed to make this possible? Or any other workable ideas?
If not, I reluctantly propose that anyone changing a dot file will need to regenerate and check in the new SVG - so that we can run scmpublish from jenkins and omit this tedious manual step on each website change.
Steve