ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaikiran Pai <>
Subject Re: Ivy - we have now moved to asciidoc for docs
Date Sat, 01 Jul 2017 13:08:24 GMT
FWIW - I just finished reviewing PR-48 (the generics changes)
Took me around an hour, the changes look fine :) I just have one comment/question about one
of the change in that PR (I have to read up the Java spec or find some necessary documentation
for it) Other than
that, the PR looks fine to me.

On 01-Jul-2017, at 5:37 PM, Nicolas Lalevée <> wrote:

Thank you very much Gintas.

These PRs are huge, so they will take a little bit of time to process.

Also, in the PR 49 and 50 I can see a lot of commits [1] [2]. For a cleaner git history, could
you rebase and squash them ? I don’t require to have one commit, for instance having the
two commits in PR 48 is great. But in these two other PR, it seems a little bit noisy.
And does PR 50 depends on PR 49 ? I can see commits from one included in the other.

I bet these « noisy » commits are due to the conflicts generated by other commits. We can
avoid these conflicts, and also avoid the work for you to resolve them: just tell us that
you have some large commit incoming, and we will try to not modify much what you are working


[1] <>
[2] <>

> Le 1 juil. 2017 à 08:07, Gintautas Grigelionis <> a écrit
> I opened a PR (well, actually two :-() to fix spelling and links that still
> point to configuration.
> Gintas
> 2017-06-30 18:44 GMT+02:00 Gintautas Grigelionis <>:
>> terminology.adoc apparently has an incorrect link on line 150,
>> configuration/statuses.html should be settings/statuses.html
>> (I get a redirect from
>> history/master/terminology.html)
>> Gintas
>> 2017-06-30 18:18 GMT+02:00 Nicolas Lalevée <>:
>>> 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.
>>> Nicolas
>>>> 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 <>
>>> é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
>>> “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:

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

View raw message