ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Ivy - we have now moved to asciidoc for docs
Date Fri, 30 Jun 2017 16:18:22 GMT
I have seen that you have qualified the source blocks, telling it is xml. Then I have done
the same for the 'Ivy File' and 'Ant Tasks’ sections. And I enabled the highlightjs integration
with acsiidoctor. I don’t find the default theme that cute (too lazy to search another one),
but it is nicer than nothing :)
I also seen some extended use of ‘code’ formatting, using ` in the asciidoc files. So
I have done as well on the sections I have worked on. And I have put a little gray background
color to improve the result. I hope it is not too invasive.

You can see the result on the site.

Probably a thing to improve are all the « since 2.x » annotations. Maybe we can have a macro
for that, which will render everywhere the same, and which will be placed everywhere the same.
Now sometimes it is at the beginning of the line, sometimes at the end, sometimes above. And
I find it being black bold a little too much.


> Le 29 juin 2017 à 15:16, Jaikiran Pai <> a écrit :
> On 29-Jun-2017, at 3:58 PM, Nicolas Lalevée <> wrote:
>>> Le 29 juin 2017 à 07:59, Jaikiran Pai <> a écrit
>>> A quick update on this one - I finished off the “settings” sections last
week. There is only one pending item that I’m trying to address in that section. The “Settings”
page[1] has a “Settings File Structure” section which tries to represent the Ivy settings
XML file structure as a tree. We have a similar one, one place else too (in Ivy file page).
We use a source code block to represent it. However, Asciidoc source code blocks are rendered
literally, so it won’t show up the links (as you’ll see in that page[1] currently). For
the Ivy page, I used “lists” to render the structure and that was “good enough"[2].
However, I can’t use the same here since Asciidoc (backed by asciidoctor generator) allows
a max list depth of 5 which means that any nested elements that exceed that depth won’t
be rendered correctly as a tree. The settings file structure goes beyond that depth limit
so it doesn’t work out well here.
>>> Ultimately, we either have to remove that section (there’s already a “Child
elements” section which _almost_ conveys the same thing) or come up with a custom asciidoc
“tree” kind of block element to render this. Any thoughts?
>> If I count correctly, there are 6 levels. So could we just remove the root element
from the tree so we save one level ? The root would be just printed as some text. Could it
then display correctly ?
> That suggestion actually worked well. I went ahead and did that change and regenerated
the latest “master” site. It looks good
> -Jaikiran
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message