Re: Ivy - we have now moved to asciidoc for docs

[Gintautas Grigelionis]

2017-07-01 18:56 GMT+02:00 Nicolas Lalevée :

>
> > Le 1 juil. 2017 à 15:27, Gintautas Grigelionis 
> a écrit :
> >
> >> 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.
> >
> > Isn't that what CSS is for? ".ivy2x:before", anyone?
>
> The thing is that we need to put at least some marker in the source. I
> don’t know if this is possible for a paragraph.
>

[ivy2x]#paragraph# ?


> And the « since » is used in different situation. Sometimes it is about
> the whole page, sometimes about a feature in the page, sometimes about an
> option (rendered as a row in a table). Might be difficult to do in CSS. But
> if there is a working patch, I would be happy to apply it.
>

For starters, can we decide whether "since 2.x" should be enclosed in
parentheses everywhere and whether the parentheses should be italicised?


> > P.S. I'm planing to work on generics in core, then tackle SVG.
> Otherwise, I
> > can just push the new Ivy logo in SVG, so everybody could get used to the
> > not-so-limbless ant :-)
>
> The doc of the master branch is already using the SVG logo of Ant, and it
> is shining on my high def screen.


So you notice the contrast with the adjacent Ivy logo? :-) There are more
SVGs waiting to be used, and, by the way, how about using SVGs/fonts in the
navigation column (open/closed/bullet)?

Gintas

[GitHub] ant-ivyde pull request #:

[twogee]

Github user twogee commented on the pull request:


https://github.com/apache/ant-ivyde/commit/b048846233286ed9bb1ae7fbeab9ab3f58983189#commitcomment-22871013
  
Isn't Eclipse Oxygen Java 8 only?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

> Le 1 juil. 2017 à 15:27, Gintautas Grigelionis  a 
> écrit :
> 
>> 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.
> 
> Isn't that what CSS is for? ".ivy2x:before", anyone?

The thing is that we need to put at least some marker in the source. I don’t 
know if this is possible for a paragraph.

And the « since » is used in different situation. Sometimes it is about the 
whole page, sometimes about a feature in the page, sometimes about an option 
(rendered as a row in a table). Might be difficult to do in CSS. But if there 
is a working patch, I would be happy to apply it.

> P.S. I'm planing to work on generics in core, then tackle SVG. Otherwise, I
> can just push the new Ivy logo in SVG, so everybody could get used to the
> not-so-limbless ant :-)

The doc of the master branch is already using the SVG logo of Ant, and it is 
shining on my high def screen.

Nicolas


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

> Le 1 juil. 2017 à 15:31, Jaikiran Pai  a écrit :
> 
> 
> On 29-Jun-2017, at 11:29 AM, Jaikiran Pai  wrote:
> 
> 
>> I’m picking up “OSGi” section next.
> 
> I have completed and pushed the migration of “OSGi” and “Using standalone” 
> sections to upstream (it’s actually live on site since yesterday). For the 
> OSGi pages, I had to reword some of the content to fix the grammar of some of 
> the sections. Also, there were a few outdated links to external projects, 
> that I had to point to new locations. One such link is the “bnd” tool link. 
> Our earlier doc here[1] points to [2] as the “bnd” tool but that link is no 
> longer live. I updated the docs to point it to [3] but I haven’t yet verified 
> that the example being explained in that page works with this tool. In fact, 
> I’m not 100% sure this new bndtools project is the same the bnd tool since 
> the project page says it’s “based” on that older tool. Either way, I’ll have 
> to verify it later that that example works fine.

BndTools is the Eclipse plugin for Bnd. I guess the teams became so close that 
they join. Seems that the new link is this one:
http://bnd.bndtools.org/ 

Nicolas

[GitHub] ant-ivy issue #48: Generics and Java 7 syntax in osgi and plugins packages

[jaikiran]

Github user jaikiran commented on the issue:

https://github.com/apache/ant-ivy/pull/48
  
>> 
https://stackoverflow.com/questions/30454635/when-using-for-a-primitive-and-a-boxed-value-is-autoboxing-done-or-is-unbox

Thanks - the JLS sections[1][2] mentioned in there answers my questions. I 
have now merged this PR.

Unfortunately, my attempt at triggering the auto closure of the PR by 
adding a trigger message to the commit hasn't succeeded this time. So please go 
ahead and manually close this PR for now.

[1] 
https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.html#jls-15.21.1
[2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.6.2


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: [GitHub] ant-ivy pull request #48: Generics and Java 7 syntax in osgi and plugins pac...

[Gintautas Grigelionis]

I believe stackoverflow has an answer [1]

Gintas

[1]
https://stackoverflow.com/questions/30454635/when-using-for-a-primitive-and-a-boxed-value-is-autoboxing-done-or-is-unbox

2017-07-01 15:56 GMT+02:00 jaikiran :

> Github user jaikiran commented on a diff in the pull request:
>
> https://github.com/apache/ant-ivy/pull/48#discussion_r125161935
>
> --- Diff: 
> src/java/org/apache/ivy/plugins/signer/bouncycastle/OpenPGPSignatureGenerator.java
> ---
> @@ -161,7 +159,7 @@ private PGPSecretKey readSecretKey(InputStream in)
> throws IOException, PGPExcept
>  key = k;
>  }
>  if ((keyId != null)
> -&& (Long.valueOf(keyId, 16).longValue() ==
> (k.getKeyID() & MASK))) {
> +&& (Long.valueOf(keyId, 16) == (k.getKeyID()
> & MASK))) {
> --- End diff --
>
> I'm not 100% sure how Java autoboxing/unboxing deals in this case.
> Does it autobox the primitive to a wrapper `Long` and do a `==` check or
> does it do a unboxing of the `Long` to a primitive and do a `==` check?
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

[GitHub] ant-ivy pull request #48: Generics and Java 7 syntax in osgi and plugins pac...

[jaikiran]

Github user jaikiran commented on a diff in the pull request:

https://github.com/apache/ant-ivy/pull/48#discussion_r125161935
  
--- Diff: 
src/java/org/apache/ivy/plugins/signer/bouncycastle/OpenPGPSignatureGenerator.java
 ---
@@ -161,7 +159,7 @@ private PGPSecretKey readSecretKey(InputStream in) 
throws IOException, PGPExcept
 key = k;
 }
 if ((keyId != null)
-&& (Long.valueOf(keyId, 16).longValue() == 
(k.getKeyID() & MASK))) {
+&& (Long.valueOf(keyId, 16) == (k.getKeyID() & 
MASK))) {
--- End diff --

I'm not 100% sure how Java autoboxing/unboxing deals in this case. Does it 
autobox the primitive to a wrapper `Long` and do a `==` check or does it do a 
unboxing of the `Long` to a primitive and do a `==` check?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #48: Generics and Java 7 syntax in osgi and plugins pac...

[jaikiran]

Github user jaikiran commented on a diff in the pull request:

https://github.com/apache/ant-ivy/pull/48#discussion_r125162592
  
--- Diff: 
src/java/org/apache/ivy/plugins/signer/bouncycastle/OpenPGPSignatureGenerator.java
 ---
@@ -161,7 +159,7 @@ private PGPSecretKey readSecretKey(InputStream in) 
throws IOException, PGPExcept
 key = k;
 }
 if ((keyId != null)
-&& (Long.valueOf(keyId, 16).longValue() == 
(k.getKeyID() & MASK))) {
+&& (Long.valueOf(keyId, 16) == (k.getKeyID() & 
MASK))) {
--- End diff --

I haven't yet found an answer to this in some of the docs I quickly 
checked. I plan to check the Java specification later tonight. But if you can 
revert this one line from the rest of the PR, then I will go ahead and merge it 
since the rest of the PR is fine. I can read up about this a bit more without 
you having to wait for this PR to be merged.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - we have now moved to asciidoc for docs

[Jaikiran Pai]

On 29-Jun-2017, at 11:29 AM, Jaikiran Pai  wrote:


> I’m picking up “OSGi” section next.

I have completed and pushed the migration of “OSGi” and “Using standalone” 
sections to upstream (it’s actually live on site since yesterday). For the OSGi 
pages, I had to reword some of the content to fix the grammar of some of the 
sections. Also, there were a few outdated links to external projects, that I 
had to point to new locations. One such link is the “bnd” tool link. Our 
earlier doc here[1] points to [2] as the “bnd” tool but that link is no longer 
live. I updated the docs to point it to [3] but I haven’t yet verified that the 
example being explained in that page works with this tool. In fact, I’m not 
100% sure this new bndtools project is the same the bnd tool since the project 
page says it’s “based” on that older tool. Either way, I’ll have to verify it 
later that that example works fine.

I’m now pick up the “Tutorials” section. 


[1] https://ant.apache.org/ivy/history/latest-milestone/osgi/standard-osgi.html
[2] http://www.aqute.biz/Code/Bnd
[3] http://bndtools.org/

-Jaikiran
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - we have now moved to asciidoc for docs

[Gintautas Grigelionis]

> 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.

Isn't that what CSS is for? ".ivy2x:before", anyone?

Gintas

P.S. I'm planing to work on generics in core, then tackle SVG. Otherwise, I
can just push the new Ivy logo in SVG, so everybody could get used to the
not-so-limbless ant :-)

Re: Ivy - we have now moved to asciidoc for docs

[Gintautas Grigelionis]

Thank you. PR 49 and 50 became one big spaghetti as I tried to catch up
with your work and learn the ropes :-)
Now, 49 is closed and 50 is squashed.

Cheers,
Gintas

2017-07-01 14:07 GMT+02:00 Nicolas Lalevée :

> 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 on.
>
> Cheers,
> Nicolas
>
> [1] https://github.com/apache/ant-ivy/pull/49/commits <
> https://github.com/apache/ant-ivy/pull/49/commits>
> [2] https://github.com/apache/ant-ivy/pull/50/commits <
> https://github.com/apache/ant-ivy/pull/50/commits>
>
> > 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 <
> g.grigelio...@gmail.com>:
> >
> >> terminology.adoc apparently has an incorrect link on line 150,
> >> configuration/statuses.html should be settings/statuses.html
> >> (I get a redirect from http://ant.apache.org/ivy/
> >> 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 <
> nicolas.lale...@hibnet.org>
> >>> 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
> >>> http://ant.apache.org/ivy/history/master/settings.html.
> 
> 

Re: Ivy - we have now moved to asciidoc for docs

[Jaikiran Pai]

On 30-Jun-2017, at 9:48 PM, Nicolas Lalevée  wrote:

> 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 :)

Thanks! Agreed that the style can be improved, but as you say, it’s better than 
the bland gray background we had for such blocks earlier.

> 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.

I actually find this change an improvement. Earlier, although such text did 
appear a bit different, it still wasn’t distinguished enough and I sometimes 
(depending on the browser/font size) had to really focus hard to distinguish it 
from regular text.

> 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.

Agreed. Maybe we could do something similar with the “experimental” 
note/section that we repeat (copy/paste really) on our OSGi pages.

-Jaikiran

> 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 
> http://ant.apache.org/ivy/history/master/settings.html.
> 
> -Jaikiran
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy issue #49: Aesthetic changes in .gitignore, build.xml and build-rele...

[twogee]

Github user twogee commented on the issue:

https://github.com/apache/ant-ivy/pull/49
  
This is a part of #50 now.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

[GitHub] ant-ivy pull request #49: Aesthetic changes in .gitignore, build.xml and bui...

[twogee]

Github user twogee closed the pull request at:

https://github.com/apache/ant-ivy/pull/49


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - we have now moved to asciidoc for docs

[Jaikiran Pai]

FWIW - I just finished reviewing PR-48 (the generics changes) 
https://github.com/apache/ant-ivy/pull/48/. 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) https://github.com/apache/ant-ivy/pull/48#discussion-diff-125161935R162. 
Other than that, the PR looks fine to me.

-Jaikiran 
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 on.

Cheers,
Nicolas

[1] https://github.com/apache/ant-ivy/pull/49/commits 

[2] https://github.com/apache/ant-ivy/pull/50/commits 


> 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 http://ant.apache.org/ivy/
>> 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  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
>>> 

Re: IVYDE-382 proposed patch

[Nicolas Lalevée]

Hi Alexander,

Yes, it would be really nice if you could create a page documenting the new 
feature.

I have just migrated the documentation of IvyDE to asciidoc, so it will be 
easier to contribute.
I have also squashed and rebased your work on this branch:
https://github.com/apache/ant-ivyde/tree/ivyDECredentials-cleaned 


To contribute you can create a pull request on this branch, we will get 
notified.

Cheers,
Nicolas


> Le 30 juin 2017 à 16:52, alexander.bl...@arctis.at a écrit :
> 
> Good afternoon, 
> 
> sorry for the delay in my reply. The last two weeks I was very busy with
> exams and work. 
> 
> We are glad that our proposed patch found its way back to the main
> development path and that perhaps it will be a part of a following
> release :-) 
> 
> Is there a way we can support you? 
> 
> Should we extend the official IvyDE doc by providing a more
> sophisticated description about the new feature (like you suggested in
> the previous mail)? 
> 
> Many greetings from Austria, 
> 
> Alexander 
> 
> Am 14.06.2017 23:56, schrieb Nicolas Lalevée:
> 
>> Hi,
>> 
>> For some reason git apply was refusing to process the patch and was just 
>> returning an error: corrupt patch at line 1964
>> 
>> So I played with git commands and work with the sources available on github.
>> I have create a branch on the ASF repo, ivyDECredentials, which has one 
>> commit which squash all the forked commit on github.
>> I have then created another branch, ivyDECredentials-cleaned, which rebase 
>> the work, remove unnecessary changes like the readme file, and did some file 
>> formatting.
>> 
>> Now it needs some review and testing in order to be merged. I'll take time 
>> to do it but if somebody else if wants to help, another pair of eyes on this 
>> is very welcomed.
>> 
>> Also would be welcomed some documentation about this new feature. The IvyDE 
>> doc is quite complete, it would be really nice to keep it at this level.
>> 
>> Nicolas
>> 
>>> Le 14 juin 2017 à 05:18, J Pai  a écrit :
>>> 
>>> Hi Alexander,
>>> 
>>> I actually just realized that your initial mail actually had a patch file 
>>> attached. I didn't notice that before and only today noticed it while 
>>> looking at the mail list archive. So assuming this applies cleanly on 
>>> latest master branch of IvyDE, I think this should be fine too, instead of 
>>> creating a PR. I am not experienced with Eclipse plugins, so I personally 
>>> won't be able to help much, but hopefully someone from the IvyDE team will 
>>> be able to review and decide about this patch. Thank you again for 
>>> contributing this.
>>> 
>>> -Jaikiran
>>> On 26-May-2017, at 8:28 AM, J Pai  wrote:
>>> 
>>> Hi Alexander,
>>> 
>>> Thank you for volunteering to provide this feature patch. I had a look a 
>>> the repo you pointed to and read the README. It does seem to contain a good 
>>> amount of work in that branch in multiple commits. 
>>> 
>>> To make it easier for whoever will decide about merging these to upstream 
>>> ant-ivyde project, would it to be possible for you to do the following:
>>> 
>>> 1. *Fork* the ant-ivyde project (on github) 
>>> https://github.com/apache/ant-ivyde/ into your account. There's a "Fork" 
>>> button on the right corner of the github page for the repo.
>>> 2. Once forked into your account, you can push your enhancement and bug fix 
>>> related commits to either your master branch of your repo or any specific 
>>> branch of your choice.
>>> - If the bug fixes are independent of the feature, then it would be good if 
>>> they are done in separate branches, so that a separate pull request (PR) 
>>> can be issued.
>>> 3. Once you are ready with the commits, you can then issue a pull request 
>>> (PR) from your repo to the "master" branch of the ant-ivyde upstream repo 
>>> https://github.com/apache/ant-ivyde/.  Typically PRs are meant to contain 
>>> commits that are all specific to a single feature or for a specific bug fix.
>>> 
>>> Once the PRs are submitted, I'm sure one or more members of the development 
>>> team who have relevant knowledge of Eclipse and the project will review 
>>> this and either merge it or provide inputs.
>>> 
>>> Thanks again for this, both Ivy and IvyDE project has been stagnant for a 
>>> while and with contributions like these, we should be able to release out a 
>>> new version soon.
>>> 
>>> -Jaikiran
>>> 
>>> On 25-May-2017, at 1:12 PM, alexander.bl...@arctis.at wrote:
>>> 
>>> Dear Sir or Madam,
>>> 
>>> as it was suggested in 
>>> https://issues.apache.org/jira/browse/IVYDE-382?focusedCommentId=16018847=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16018847,
>>>  we are sending you our proposed patch for 
>>> https://issues.apache.org/jira/browse/IVYDE-382. The corresponding 
>>> patch-file is attached to this email. The source code is available at 
>>> 

Re: Ivy - we have now moved to asciidoc for docs

[Nicolas Lalevée]

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 on.

Cheers,
Nicolas

[1] https://github.com/apache/ant-ivy/pull/49/commits 

[2] https://github.com/apache/ant-ivy/pull/50/commits 


> 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 http://ant.apache.org/ivy/
>> 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  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
>>> http://ant.apache.org/ivy/history/master/settings.html.
 
 -Jaikiran
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org
 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>>> For additional commands, e-mail: dev-h...@ant.apache.org
>>> 
>>> 
>> 

Re: IVYDE-382 proposed patch

[alexander . blaas]

Good afternoon, 

sorry for the delay in my reply. The last two weeks I was very busy with
exams and work. 

We are glad that our proposed patch found its way back to the main
development path and that perhaps it will be a part of a following
release :-) 

Is there a way we can support you? 

Should we extend the official IvyDE doc by providing a more
sophisticated description about the new feature (like you suggested in
the previous mail)? 

Many greetings from Austria, 

Alexander 

Am 14.06.2017 23:56, schrieb Nicolas Lalevée:

> Hi,
> 
> For some reason git apply was refusing to process the patch and was just 
> returning an error: corrupt patch at line 1964
> 
> So I played with git commands and work with the sources available on github.
> I have create a branch on the ASF repo, ivyDECredentials, which has one 
> commit which squash all the forked commit on github.
> I have then created another branch, ivyDECredentials-cleaned, which rebase 
> the work, remove unnecessary changes like the readme file, and did some file 
> formatting.
> 
> Now it needs some review and testing in order to be merged. I'll take time to 
> do it but if somebody else if wants to help, another pair of eyes on this is 
> very welcomed.
> 
> Also would be welcomed some documentation about this new feature. The IvyDE 
> doc is quite complete, it would be really nice to keep it at this level.
> 
> Nicolas
> 
>> Le 14 juin 2017 à 05:18, J Pai  a écrit :
>> 
>> Hi Alexander,
>> 
>> I actually just realized that your initial mail actually had a patch file 
>> attached. I didn't notice that before and only today noticed it while 
>> looking at the mail list archive. So assuming this applies cleanly on latest 
>> master branch of IvyDE, I think this should be fine too, instead of creating 
>> a PR. I am not experienced with Eclipse plugins, so I personally won't be 
>> able to help much, but hopefully someone from the IvyDE team will be able to 
>> review and decide about this patch. Thank you again for contributing this.
>> 
>> -Jaikiran
>> On 26-May-2017, at 8:28 AM, J Pai  wrote:
>> 
>> Hi Alexander,
>> 
>> Thank you for volunteering to provide this feature patch. I had a look a the 
>> repo you pointed to and read the README. It does seem to contain a good 
>> amount of work in that branch in multiple commits. 
>> 
>> To make it easier for whoever will decide about merging these to upstream 
>> ant-ivyde project, would it to be possible for you to do the following:
>> 
>> 1. *Fork* the ant-ivyde project (on github) 
>> https://github.com/apache/ant-ivyde/ into your account. There's a "Fork" 
>> button on the right corner of the github page for the repo.
>> 2. Once forked into your account, you can push your enhancement and bug fix 
>> related commits to either your master branch of your repo or any specific 
>> branch of your choice.
>> - If the bug fixes are independent of the feature, then it would be good if 
>> they are done in separate branches, so that a separate pull request (PR) can 
>> be issued.
>> 3. Once you are ready with the commits, you can then issue a pull request 
>> (PR) from your repo to the "master" branch of the ant-ivyde upstream repo 
>> https://github.com/apache/ant-ivyde/.  Typically PRs are meant to contain 
>> commits that are all specific to a single feature or for a specific bug fix.
>> 
>> Once the PRs are submitted, I'm sure one or more members of the development 
>> team who have relevant knowledge of Eclipse and the project will review this 
>> and either merge it or provide inputs.
>> 
>> Thanks again for this, both Ivy and IvyDE project has been stagnant for a 
>> while and with contributions like these, we should be able to release out a 
>> new version soon.
>> 
>> -Jaikiran
>> 
>> On 25-May-2017, at 1:12 PM, alexander.bl...@arctis.at wrote:
>> 
>> Dear Sir or Madam,
>> 
>> as it was suggested in 
>> https://issues.apache.org/jira/browse/IVYDE-382?focusedCommentId=16018847=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16018847,
>>  we are sending you our proposed patch for 
>> https://issues.apache.org/jira/browse/IVYDE-382. The corresponding 
>> patch-file is attached to this email. The source code is available at 
>> https://github.com/alex-bl/ivyDEextension/tree/ivyDECredentials in the 
>> branch "ivyDECredentials". 
>> 
>> Yours sincerely,
>> 
>> Alexander Blaas
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org

Re: Ivy - we have now moved to asciidoc for docs

[Gintautas Grigelionis]

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 http://ant.apache.org/ivy/
> 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  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
>> http://ant.apache.org/ivy/history/master/settings.html.
>> >
>> > -Jaikiran
>> >
>> >
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> > For additional commands, e-mail: dev-h...@ant.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
>