Re: Ivy documentation with asciidoc

[Gintautas Grigelionis]

2017-05-31 23:00 GMT+02:00 Nicolas Lalevée :

>
> > Le 31 mai 2017 à 19:47, Gintautas Grigelionis 
> a écrit :
> >

> Also, external links must be pruned and/or directed to Internet Archive
> :-(
> > The tutorial of yEd must be revised, version 3 has many more controls. I
> > converted the odg diagrams to svg, and started looking at Ivy report/yEd
> > screenshots. The original Ivy logo is unfortunately too low resolution
> for
> > simple tracing :-( Is this all there is?
>
> The only version of the logo we have is in the svn.
>

That's a pity.

A couple of related questions: Apache Incubator has changed the logo,
should the new logo from their press release kit be used in documentation
instead? Next, there is an "Apache Ant Group" logo that looks like the
regular ASF feather 
mirrored horisontally with the text on top of it. Is that an official logo?

Gintas

Re: Ivy documentation with asciidoc

[Nicolas Lalevée]

> Le 31 mai 2017 à 19:47, Gintautas Grigelionis  a 
> écrit :
> 
> I looked at the documentation: both
> http://ant.apache.org/ivy/history/trunk/tutorial/start.html 
>  and
> https://ant.apache.org/ivy/history/latest-milestone/tutorial/start.html 
> 
> have black rectangles.

There should be the logs generated automatically there. These logs are 
generated by the task generate-tutorial-output in the build-release.xml in the 
sources of Ivy.

I think the way we generate the website is incorrect regarding these logs, 
because building the site is only about calling xooki, not generate the 
tutorial logs. Hence the empty black rectangles. This need to be reviewed.
Probably while migrating to asciidoc, we should do like Matt suggested. When 
releasing, also do a build of the doc, which will include the generation of the 
logs of the tutorial, and then push manually the doc into the svn of the site.

> Also, external links must be pruned and/or directed to Internet Archive :-(
> The tutorial of yEd must be revised, version 3 has many more controls. I
> converted the odg diagrams to svg, and started looking at Ivy report/yEd
> screenshots. The original Ivy logo is unfortunately too low resolution for
> simple tracing :-( Is this all there is?

The only version of the logo we have is in the svn.

Nicolas

> 
> Gintas
> 
> 2017-05-31 18:20 GMT+02:00 Nicolas Lalevée  >:
> 
>> 
>>> Le 31 mai 2017 à 17:53, J Pai >> > a écrit :
>>> 
>>> 
>>> On 31-May-2017, at 9:02 PM, Nicolas Lalevée >> 
>> >> 
>> wrote:
>>> 
>>> 
 Le 31 mai 2017 à 15:34, J Pai  a écrit :
 
 One thing I just noticed in the generated adoc files is that “external”
>> links that are part of the original xooki backed .html files are not being
>> generated as links in the converted adoc. To see a couple of example, take
>> a look at this hibnet.org/tmp/ivy-asciidoc/index.html page. The “Apache
>> License” in this sentence:
 
> Ivy is open source and released under a very permissive Apache License.
> 
 
 
 and the “features” in :
 
> Ivy has a lot of powerful features
 
 are actually link references in the original xooki backed docs of the
>> form [[license Apache License]] and [[features]].
>>> 
 It seems that xooki doesn’t generate links either:
 http://ant.apache.org/ivy/history/trunk/index.html 
  <
>> http://ant.apache.org/ivy/history/trunk/index.html 
>> > <
>> http://ant.apache.org/ivy/history/trunk/index.html 
>>  <
>> http://ant.apache.org/ivy/history/trunk/index.html 
>> >>
 
 Probably the pointed pages have been deleted or moved and these links
>> have not been updated.
>>> 
>>> 
>>> I suspect it has to do with how/where those HTMLs got generated. Because
>> in the latest-milestone live ones, I see them as links on this page
>> https://ant.apache.org/ivy/history/latest-milestone/index.html 
>>  <
>> https://ant.apache.org/ivy/history/latest-milestone/index.html 
>> >
>> 
>> Good catch.
>> Then the links should be absolute since they are not referencing something
>> within the doc.
>> 
>> Nicolas

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

[Maarten Coene]

I don't see how Ivy could resolve the old ant-compress ivy.xml files without 
using very special artifact patterns.So my guess is that Ivy users of 
ant-compress just use the pom.xml file.

So I'd say we should fix the ivy.xml.
Maarten

  Van: Stefan Bodewig 
 Aan: dev@ant.apache.org 
 Verzonden: woensdag 31 mei 17:34 2017
 Onderwerp: [antlibs] Break Backwards Compatibility of Ivy Coordinates?
   
Hi all

this is an excerpt from the cancelled vote thread for the compress
antlib.

2017-05-31 16:40 GMT+02:00 Stefan Bodewig :

> I've just realized that the ivy.xml file I've published to Nexus has
> completely different coordinates from the one used in earlier
> releases. It used to be
>
>              module="ant" ...>
>        
> for 1.5 RC1 it is
>
>              module="ant-compress" ...>
>        
> and the current master branch would create
>
>              module="ant-compress"
>          

Re: Ivy documentation with asciidoc

[Gintautas Grigelionis]

I looked at the documentation: both
http://ant.apache.org/ivy/history/trunk/tutorial/start.html and
https://ant.apache.org/ivy/history/latest-milestone/tutorial/start.html
have black rectangles.

Also, external links must be pruned and/or directed to Internet Archive :-(
The tutorial of yEd must be revised, version 3 has many more controls. I
converted the odg diagrams to svg, and started looking at Ivy report/yEd
screenshots. The original Ivy logo is unfortunately too low resolution for
simple tracing :-( Is this all there is?

Gintas

2017-05-31 18:20 GMT+02:00 Nicolas Lalevée :

>
> > Le 31 mai 2017 à 17:53, J Pai  a écrit :
> >
> >
> > On 31-May-2017, at 9:02 PM, Nicolas Lalevée  > wrote:
> >
> >
> >> Le 31 mai 2017 à 15:34, J Pai  a écrit :
> >>
> >> One thing I just noticed in the generated adoc files is that “external”
> links that are part of the original xooki backed .html files are not being
> generated as links in the converted adoc. To see a couple of example, take
> a look at this hibnet.org/tmp/ivy-asciidoc/index.html page. The “Apache
> License” in this sentence:
> >>
> >>> Ivy is open source and released under a very permissive Apache License.
> >>>
> >>
> >>
> >> and the “features” in :
> >>
> >>> Ivy has a lot of powerful features
> >>
> >> are actually link references in the original xooki backed docs of the
> form [[license Apache License]] and [[features]].
> >
> >> It seems that xooki doesn’t generate links either:
> >> http://ant.apache.org/ivy/history/trunk/index.html <
> http://ant.apache.org/ivy/history/trunk/index.html> <
> http://ant.apache.org/ivy/history/trunk/index.html <
> http://ant.apache.org/ivy/history/trunk/index.html>>
> >>
> >> Probably the pointed pages have been deleted or moved and these links
> have not been updated.
> >
> >
> > I suspect it has to do with how/where those HTMLs got generated. Because
> in the latest-milestone live ones, I see them as links on this page
> https://ant.apache.org/ivy/history/latest-milestone/index.html <
> https://ant.apache.org/ivy/history/latest-milestone/index.html>
>
> Good catch.
> Then the links should be absolute since they are not referencing something
> within the doc.
>
> Nicolas
>
>

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

[Gintautas Grigelionis]

Then option 2 is a given: errare humanum est sed in errare perseverare
diabolicum :-)

Gintas

2017-05-31 18:11 GMT+02:00 Stefan Bodewig :

> On 2017-05-31, Gintautas Grigelionis wrote:
>
> > can't you just publish new ivy.xml?
>
> we can't overwrite existing files in Maven Central.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: Ivy documentation with asciidoc

[Nicolas Lalevée]

> Le 31 mai 2017 à 17:53, J Pai  a écrit :
> 
> 
> On 31-May-2017, at 9:02 PM, Nicolas Lalevée  > wrote:
> 
> 
>> Le 31 mai 2017 à 15:34, J Pai  a écrit :
>> 
>> One thing I just noticed in the generated adoc files is that “external” 
>> links that are part of the original xooki backed .html files are not being 
>> generated as links in the converted adoc. To see a couple of example, take a 
>> look at this hibnet.org/tmp/ivy-asciidoc/index.html page. The “Apache 
>> License” in this sentence:
>> 
>>> Ivy is open source and released under a very permissive Apache License.
>>> 
>> 
>> 
>> and the “features” in :
>> 
>>> Ivy has a lot of powerful features
>> 
>> are actually link references in the original xooki backed docs of the form 
>> [[license Apache License]] and [[features]].
> 
>> It seems that xooki doesn’t generate links either:
>> http://ant.apache.org/ivy/history/trunk/index.html 
>>  
>> > >
>> 
>> Probably the pointed pages have been deleted or moved and these links have 
>> not been updated.
> 
> 
> I suspect it has to do with how/where those HTMLs got generated. Because in 
> the latest-milestone live ones, I see them as links on this page 
> https://ant.apache.org/ivy/history/latest-milestone/index.html 
> 

Good catch.
Then the links should be absolute since they are not referencing something 
within the doc.

Nicolas

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

[Stefan Bodewig]

On 2017-05-31, Gintautas Grigelionis wrote:

> can't you just publish new ivy.xml?

we can't overwrite existing files in Maven Central.

Stefan

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

Re: [antlibs] Break Backwards Compatibility of Ivy Coordinates?

[Gintautas Grigelionis]

Hi,

can't you just publish new ivy.xml?

Gintas

2017-05-31 17:34 GMT+02:00 Stefan Bodewig :

> Hi all
>
> this is an excerpt from the cancelled vote thread for the compress
> antlib.
>
> 2017-05-31 16:40 GMT+02:00 Stefan Bodewig :
>
> > I've just realized that the ivy.xml file I've published to Nexus has
> > completely different coordinates from the one used in earlier
> > releases. It used to be
> >
> >  >   module="ant" ...>
> >  >
> > for 1.5 RC1 it is
> >
> >  >   module="ant-compress" ...>
> >  >
> > and the current master branch would create
> >
> >  >   module="ant-compress"
> >  
> and as Gintas points out, master is the only one that is using Ivy
> coordinates the way they are intended to be.
>
> All antlibs builds except for Compress are currently in a state that
> makes it impossible to release them without making changes and Compress
> is "correct" after all. So now would be a good time to decide what to
> do.
>
> We could violate Ivy's concepts and go back to what we've done before -
> the first example above. This is what the two releases of Dotnet, the
> four releases of AntUnit ant the five releases of Compress have done so
> far.
>
> The other option is to fix all Antlibs to be in line with Ivy's concepts
> (as Compress is inside master right now). This runs the risk of breaking
> things for people who use Ivy to retrieve the Antlibs (or maybe not, if
> they pick them up via their POMs as those have been correct) with all
> future releases of the three Antlibs that have had releases.
>
> I tend to go with the second option and list it as a backwards
> incompatible change.
>
> Any preferences?
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

[antlibs] Break Backwards Compatibility of Ivy Coordinates?

[Stefan Bodewig]

Hi all

this is an excerpt from the cancelled vote thread for the compress
antlib.

2017-05-31 16:40 GMT+02:00 Stefan Bodewig :

> I've just realized that the ivy.xml file I've published to Nexus has
> completely different coordinates from the one used in earlier
> releases. It used to be
>
>module="ant" ...>
> 
> for 1.5 RC1 it is
>
>module="ant-compress" ...>
> 
> and the current master branch would create
>
>module="ant-compress"
>  

Re: Ivy documentation with asciidoc

[Nicolas Lalevée]

> Le 31 mai 2017 à 15:34, J Pai  a écrit :
> 
> One thing I just noticed in the generated adoc files is that “external” links 
> that are part of the original xooki backed .html files are not being 
> generated as links in the converted adoc. To see a couple of example, take a 
> look at this hibnet.org/tmp/ivy-asciidoc/index.html page. The “Apache 
> License” in this sentence:
> 
>> Ivy is open source and released under a very permissive Apache License.
>> 
> 
> 
> and the “features” in :
> 
>> Ivy has a lot of powerful features
> 
> are actually link references in the original xooki backed docs of the form 
> [[license Apache License]] and [[features]].

It seems that xooki doesn’t generate links either:
http://ant.apache.org/ivy/history/trunk/index.html 


Probably the pointed pages have been deleted or moved and these links have not 
been updated.

Nicolas

> 
> -Jaikiran
> 
> On 31-May-2017, at 6:50 PM, J Pai  wrote:
> 
> I had some time today and decided to test this branch out locally. I was able 
> to generate the docs without any hassle. The conversion works fine which is a 
> great thing.
> 
> There are certain warning about the heading/section level we use in the 
> generated adoc files, for top level heading:
> 
>> [asciidoctor:convert] asciidoctor: WARNING: dependency.adoc: line 7: section 
>> title out of sequence: expected level 1, got level 2
> 
> 
> but that’s pretty much it in terms of build time warnings/errors.
> 
> In one of my other mails I had noted that if not in this release then maybe 
> in next release we can focus on this xooki to asciidoc conversion. But at 
> that time I wasn’t aware that Nicolas had already done the bulk of this job 
> by implementing this tool. 
> 
> So IMO, after fixing/finalizing some of those WARN related issues, we can 
> probably just go ahead and use this tool to convert our current docs to adoc 
> as a one time thing in our master branch. Till we are comfortable and are 
> sure that the conversion is done fully, we can keep the old xooki backed docs 
> as-is but just not update/add any new stuff in them. Given how nicely this 
> tool works and the fact that it isn’t breaking anything, I don’t think we 
> will have to maintain a separate branch to deal with this migration.
> 
> Any thoughts?
> 
> -Jaikiran
> 
> On 25-May-2017, at 7:55 PM, Nicolas Lalevée  
> wrote:
> 
> 
>> Le 25 mai 2017 à 16:17, Matt Sicker  a écrit :
>> 
>> Merge commits always spam the commits list which, while annoying, I've
>> learned to mass-delete whenever it happens. ;)
>> 
>> I looked at some random changes and found a couple markup typos, but
>> otherwise it looks like it converted well enough.
> 
> Yes, I have stopped one too. Some things will need to be manually fixed after 
> the automatic conversion.
> 
>> I'm more familiar with the maven plugins for site management, so I'm not
>> sure about the integration aspects, but worst case scenario, can't you just
>> commit the parts to svnpubsub on release?
> 
> If you look at the menu on the left, it is present on each page, so it means 
> that for any new file or deleted file, every page has to be regenerated. The 
> consequence it that generating a page of the site has to be aware of the list 
> of all the pages of the documentation.
> 
> But we can imagine that we uncouple the documentation, like it is being done 
> for the old versions of the documentation, in the « history » section, by 
> just having a link. So yes we could some manual copy and publish to svnpubsub 
> on release.
> 
> Nicolas
> 
>> 
>> On 25 May 2017 at 09:00, Nicolas Lalevée  wrote:
>> 
>>> I have updated the branch xooki2asciidoc. The merge generated 50 emails,
>>> which I still find weird, I would expect just one mail about the commit of
>>> the merge.
>>> 
>>> I can see the current status of the transformation of the xooki source
>>> into asciidoc source and then the generated html from that here:
>>> http://hibnet.org/tmp/ivy-asciidoc/index.html >> asciidoc/index.html>
>>> 
>>> It seems pretty good, but I didn’t looked to most of the pages.
>>> 
>>> Before going further, we need to figure out how it would be integrated to
>>> the website since it is also managed by xooki. The site and the
>>> documentation are tidily coupled by the toc which is managed by xooki.
>>> 
>>> Nicolas
>>> 
>>> 
>> 
>> 
>> -- 
>> Matt Sicker 
> 
> 
> -
> 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: [CANCEL][VOTE] Release Compress Antlib 1.5 based on RC1

[Stefan Bodewig]

On 2017-05-31, Gintautas Grigelionis wrote:

> Luckily, all the old poms have correct coordinates :-) They MUST be the
> same in pom.xml and ivy.xml

Well. Ironically the folks working on Ant libs are more familiar with
Maven then with Ivy, at least I am.

After re-reading the Ivy docs I fully have to agree with

>> the master is correct and all previous coordinates as well as RC1 are
>> wrong.

and will start a separate thread for this.

Stefan

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

Re: Ivy documentation with asciidoc

[Nicolas Lalevée]

> Le 31 mai 2017 à 15:20, J Pai  a écrit :
> 
> I had some time today and decided to test this branch out locally. I was able 
> to generate the docs without any hassle. The conversion works fine which is a 
> great thing.
> 
> There are certain warning about the heading/section level we use in the 
> generated adoc files, for top level heading:
> 
>> [asciidoctor:convert] asciidoctor: WARNING: dependency.adoc: line 7: section 
>> title out of sequence: expected level 1, got level 2
> 
> 
> but that’s pretty much it in terms of build time warnings/errors.
> 
> In one of my other mails I had noted that if not in this release then maybe 
> in next release we can focus on this xooki to asciidoc conversion. But at 
> that time I wasn’t aware that Nicolas had already done the bulk of this job 
> by implementing this tool. 
> 
> So IMO, after fixing/finalizing some of those WARN related issues, we can 
> probably just go ahead and use this tool to convert our current docs to adoc 
> as a one time thing in our master branch. Till we are comfortable and are 
> sure that the conversion is done fully, we can keep the old xooki backed docs 
> as-is but just not update/add any new stuff in them. Given how nicely this 
> tool works and the fact that it isn’t breaking anything, I don’t think we 
> will have to maintain a separate branch to deal with this migration.

The goal of this tool is not to generate completely asciidoc compatible source, 
just do most of the stuff automatically. For instance, fixing the issue with 
the title level automatically will be hard I think, at least harder than fixing 
it manually afterward.
So the question about it being ready or not, is more about if we are ready to 
fix manually what is not being correctly converted.

About keeping the old xooki sources: I don’t think this will be necessary, we 
have git for that. But probably just before migrating, we could generate the 
doc one last time with xooki and keep it somewhere so we can compare the final 
result while fixing manually the asciidoc sources.

Then about when to do it: I have no objection to when, as long as people are 
motivated to do it.

Nicolas


> Any thoughts?
> 
> -Jaikiran
> 
> On 25-May-2017, at 7:55 PM, Nicolas Lalevée  
> wrote:
> 
> 
>> Le 25 mai 2017 à 16:17, Matt Sicker  a écrit :
>> 
>> Merge commits always spam the commits list which, while annoying, I've
>> learned to mass-delete whenever it happens. ;)
>> 
>> I looked at some random changes and found a couple markup typos, but
>> otherwise it looks like it converted well enough.
> 
> Yes, I have stopped one too. Some things will need to be manually fixed after 
> the automatic conversion.
> 
>> I'm more familiar with the maven plugins for site management, so I'm not
>> sure about the integration aspects, but worst case scenario, can't you just
>> commit the parts to svnpubsub on release?
> 
> If you look at the menu on the left, it is present on each page, so it means 
> that for any new file or deleted file, every page has to be regenerated. The 
> consequence it that generating a page of the site has to be aware of the list 
> of all the pages of the documentation.
> 
> But we can imagine that we uncouple the documentation, like it is being done 
> for the old versions of the documentation, in the « history » section, by 
> just having a link. So yes we could some manual copy and publish to svnpubsub 
> on release.
> 
> Nicolas
> 
>> 
>> On 25 May 2017 at 09:00, Nicolas Lalevée  wrote:
>> 
>>> I have updated the branch xooki2asciidoc. The merge generated 50 emails,
>>> which I still find weird, I would expect just one mail about the commit of
>>> the merge.
>>> 
>>> I can see the current status of the transformation of the xooki source
>>> into asciidoc source and then the generated html from that here:
>>> http://hibnet.org/tmp/ivy-asciidoc/index.html >> asciidoc/index.html>
>>> 
>>> It seems pretty good, but I didn’t looked to most of the pages.
>>> 
>>> Before going further, we need to figure out how it would be integrated to
>>> the website since it is also managed by xooki. The site and the
>>> documentation are tidily coupled by the toc which is managed by xooki.
>>> 
>>> Nicolas
>>> 
>>> 
>> 
>> 
>> -- 
>> Matt Sicker 
> 
> 
> -
> 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

Re: [VOTE] Release Compress Antlib 1.5 based on RC1

[Maarten Coene]

No Stefan, I was just wondering if it was normal that this file didn't contain 
the release date.If the current situation is fine for you, I'll give my vote.
Maarten

  Van: Stefan Bodewig 
 Aan: dev@ant.apache.org 
 Verzonden: woensdag 31 mei 14:39 2017
 Onderwerp: Re: [VOTE] Release Compress Antlib 1.5 based on RC1
   
Maarten, Jan

right now this only has my implicit vote. Would you be more inclined to
vote if the date was included inside the changelog? If so, I'll re-roll
the release.

Stefan

On 2017-05-31, Maarten Coene wrote:

> Why not simply  ?That is the date 
> the vote started and the binaries were built?Or perhaps you could add a few 
> days to it and make sure the vote ends at that date?

> It's just strange when reading the documentation of a released version to see 
> that it's 'unreleased' or 'during-release'...

> Maarten


>      Van: "Matèrne, Jan (RZF, Ref 410)" 
>  Aan: Ant Developers List 
>  Verzonden: woensdag 31 mei 10:25 2017
>  Onderwerp: AW: [VOTE] Release Compress Antlib 1.5 based on RC1

> Maybe
> ?

> Jan

> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:bode...@apache.org]
> Gesendet: Mittwoch, 31. Mai 2017 09:46
> An: dev@ant.apache.org
> Betreff: Re: [VOTE] Release Compress Antlib 1.5 based on RC1

> On 2017-05-31, Maarten Coene wrote:

>> The changes.xml still contains the following line:> date="unreleased">
>> I'm not sure this should block the release, but I think it would be better 
>> to fill in the correct date.

> This is a chicken and egg problem. As long as the vote hasn't passed, I
> don't know the release date :-)

> Stefan

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


   

Re: Ivy documentation with asciidoc

[Gintautas Grigelionis]

Great news! How about SVG for images? I thought about tracing the Ivy logo;
also, dependency graphs made with yEd can be saved in SVG. What about using
fonts (eg genericons) instead of images for arrows etc?

Gintas

2017-05-31 15:20 GMT+02:00 J Pai :

> I had some time today and decided to test this branch out locally. I was
> able to generate the docs without any hassle. The conversion works fine
> which is a great thing.
>
> There are certain warning about the heading/section level we use in the
> generated adoc files, for top level heading:
>
> > [asciidoctor:convert] asciidoctor: WARNING: dependency.adoc: line 7:
> section title out of sequence: expected level 1, got level 2
>
>
> but that’s pretty much it in terms of build time warnings/errors.
>
> In one of my other mails I had noted that if not in this release then
> maybe in next release we can focus on this xooki to asciidoc conversion.
> But at that time I wasn’t aware that Nicolas had already done the bulk of
> this job by implementing this tool.
>
> So IMO, after fixing/finalizing some of those WARN related issues, we can
> probably just go ahead and use this tool to convert our current docs to
> adoc as a one time thing in our master branch. Till we are comfortable and
> are sure that the conversion is done fully, we can keep the old xooki
> backed docs as-is but just not update/add any new stuff in them. Given how
> nicely this tool works and the fact that it isn’t breaking anything, I
> don’t think we will have to maintain a separate branch to deal with this
> migration.
>
> Any thoughts?
>
> -Jaikiran
>
> On 25-May-2017, at 7:55 PM, Nicolas Lalevée 
> wrote:
>
>
> > Le 25 mai 2017 à 16:17, Matt Sicker  a écrit :
> >
> > Merge commits always spam the commits list which, while annoying, I've
> > learned to mass-delete whenever it happens. ;)
> >
> > I looked at some random changes and found a couple markup typos, but
> > otherwise it looks like it converted well enough.
>
> Yes, I have stopped one too. Some things will need to be manually fixed
> after the automatic conversion.
>
> > I'm more familiar with the maven plugins for site management, so I'm not
> > sure about the integration aspects, but worst case scenario, can't you
> just
> > commit the parts to svnpubsub on release?
>
> If you look at the menu on the left, it is present on each page, so it
> means that for any new file or deleted file, every page has to be
> regenerated. The consequence it that generating a page of the site has to
> be aware of the list of all the pages of the documentation.
>
> But we can imagine that we uncouple the documentation, like it is being
> done for the old versions of the documentation, in the « history » section,
> by just having a link. So yes we could some manual copy and publish to
> svnpubsub on release.
>
> Nicolas
>
> >
> > On 25 May 2017 at 09:00, Nicolas Lalevée 
> wrote:
> >
> >> I have updated the branch xooki2asciidoc. The merge generated 50 emails,
> >> which I still find weird, I would expect just one mail about the commit
> of
> >> the merge.
> >>
> >> I can see the current status of the transformation of the xooki source
> >> into asciidoc source and then the generated html from that here:
> >> http://hibnet.org/tmp/ivy-asciidoc/index.html <
> http://hibnet.org/tmp/ivy-
> >> asciidoc/index.html>
> >>
> >> It seems pretty good, but I didn’t looked to most of the pages.
> >>
> >> Before going further, we need to figure out how it would be integrated
> to
> >> the website since it is also managed by xooki. The site and the
> >> documentation are tidily coupled by the toc which is managed by xooki.
> >>
> >> Nicolas
> >>
> >>
> >
> >
> > --
> > Matt Sicker 
>
>
> -
> 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 documentation with asciidoc

[J Pai]

One thing I just noticed in the generated adoc files is that “external” links 
that are part of the original xooki backed .html files are not being generated 
as links in the converted adoc. To see a couple of example, take a look at this 
hibnet.org/tmp/ivy-asciidoc/index.html page. The “Apache License” in this 
sentence:

> Ivy is open source and released under a very permissive Apache License.
> 


and the “features” in :

> Ivy has a lot of powerful features

are actually link references in the original xooki backed docs of the form 
[[license Apache License]] and [[features]].

-Jaikiran

On 31-May-2017, at 6:50 PM, J Pai  wrote:

I had some time today and decided to test this branch out locally. I was able 
to generate the docs without any hassle. The conversion works fine which is a 
great thing.

There are certain warning about the heading/section level we use in the 
generated adoc files, for top level heading:

> [asciidoctor:convert] asciidoctor: WARNING: dependency.adoc: line 7: section 
> title out of sequence: expected level 1, got level 2


but that’s pretty much it in terms of build time warnings/errors.

In one of my other mails I had noted that if not in this release then maybe in 
next release we can focus on this xooki to asciidoc conversion. But at that 
time I wasn’t aware that Nicolas had already done the bulk of this job by 
implementing this tool. 

So IMO, after fixing/finalizing some of those WARN related issues, we can 
probably just go ahead and use this tool to convert our current docs to adoc as 
a one time thing in our master branch. Till we are comfortable and are sure 
that the conversion is done fully, we can keep the old xooki backed docs as-is 
but just not update/add any new stuff in them. Given how nicely this tool works 
and the fact that it isn’t breaking anything, I don’t think we will have to 
maintain a separate branch to deal with this migration.

Any thoughts?

-Jaikiran

On 25-May-2017, at 7:55 PM, Nicolas Lalevée  wrote:


> Le 25 mai 2017 à 16:17, Matt Sicker  a écrit :
> 
> Merge commits always spam the commits list which, while annoying, I've
> learned to mass-delete whenever it happens. ;)
> 
> I looked at some random changes and found a couple markup typos, but
> otherwise it looks like it converted well enough.

Yes, I have stopped one too. Some things will need to be manually fixed after 
the automatic conversion.

> I'm more familiar with the maven plugins for site management, so I'm not
> sure about the integration aspects, but worst case scenario, can't you just
> commit the parts to svnpubsub on release?

If you look at the menu on the left, it is present on each page, so it means 
that for any new file or deleted file, every page has to be regenerated. The 
consequence it that generating a page of the site has to be aware of the list 
of all the pages of the documentation.

But we can imagine that we uncouple the documentation, like it is being done 
for the old versions of the documentation, in the « history » section, by just 
having a link. So yes we could some manual copy and publish to svnpubsub on 
release.

Nicolas

> 
> On 25 May 2017 at 09:00, Nicolas Lalevée  wrote:
> 
>> I have updated the branch xooki2asciidoc. The merge generated 50 emails,
>> which I still find weird, I would expect just one mail about the commit of
>> the merge.
>> 
>> I can see the current status of the transformation of the xooki source
>> into asciidoc source and then the generated html from that here:
>> http://hibnet.org/tmp/ivy-asciidoc/index.html > asciidoc/index.html>
>> 
>> It seems pretty good, but I didn’t looked to most of the pages.
>> 
>> Before going further, we need to figure out how it would be integrated to
>> the website since it is also managed by xooki. The site and the
>> documentation are tidily coupled by the toc which is managed by xooki.
>> 
>> Nicolas
>> 
>> 
> 
> 
> -- 
> Matt Sicker 


-
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 documentation with asciidoc

[J Pai]

I had some time today and decided to test this branch out locally. I was able 
to generate the docs without any hassle. The conversion works fine which is a 
great thing.

There are certain warning about the heading/section level we use in the 
generated adoc files, for top level heading:

> [asciidoctor:convert] asciidoctor: WARNING: dependency.adoc: line 7: section 
> title out of sequence: expected level 1, got level 2


but that’s pretty much it in terms of build time warnings/errors.

In one of my other mails I had noted that if not in this release then maybe in 
next release we can focus on this xooki to asciidoc conversion. But at that 
time I wasn’t aware that Nicolas had already done the bulk of this job by 
implementing this tool. 

So IMO, after fixing/finalizing some of those WARN related issues, we can 
probably just go ahead and use this tool to convert our current docs to adoc as 
a one time thing in our master branch. Till we are comfortable and are sure 
that the conversion is done fully, we can keep the old xooki backed docs as-is 
but just not update/add any new stuff in them. Given how nicely this tool works 
and the fact that it isn’t breaking anything, I don’t think we will have to 
maintain a separate branch to deal with this migration.

Any thoughts?

-Jaikiran

On 25-May-2017, at 7:55 PM, Nicolas Lalevée  wrote:


> Le 25 mai 2017 à 16:17, Matt Sicker  a écrit :
> 
> Merge commits always spam the commits list which, while annoying, I've
> learned to mass-delete whenever it happens. ;)
> 
> I looked at some random changes and found a couple markup typos, but
> otherwise it looks like it converted well enough.

Yes, I have stopped one too. Some things will need to be manually fixed after 
the automatic conversion.

> I'm more familiar with the maven plugins for site management, so I'm not
> sure about the integration aspects, but worst case scenario, can't you just
> commit the parts to svnpubsub on release?

If you look at the menu on the left, it is present on each page, so it means 
that for any new file or deleted file, every page has to be regenerated. The 
consequence it that generating a page of the site has to be aware of the list 
of all the pages of the documentation.

But we can imagine that we uncouple the documentation, like it is being done 
for the old versions of the documentation, in the « history » section, by just 
having a link. So yes we could some manual copy and publish to svnpubsub on 
release.

Nicolas

> 
> On 25 May 2017 at 09:00, Nicolas Lalevée  wrote:
> 
>> I have updated the branch xooki2asciidoc. The merge generated 50 emails,
>> which I still find weird, I would expect just one mail about the commit of
>> the merge.
>> 
>> I can see the current status of the transformation of the xooki source
>> into asciidoc source and then the generated html from that here:
>> http://hibnet.org/tmp/ivy-asciidoc/index.html > asciidoc/index.html>
>> 
>> It seems pretty good, but I didn’t looked to most of the pages.
>> 
>> Before going further, we need to figure out how it would be integrated to
>> the website since it is also managed by xooki. The site and the
>> documentation are tidily coupled by the toc which is managed by xooki.
>> 
>> Nicolas
>> 
>> 
> 
> 
> -- 
> Matt Sicker 


-
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: [VOTE] Release Compress Antlib 1.5 based on RC1

[Stefan Bodewig]

Maarten, Jan

right now this only has my implicit vote. Would you be more inclined to
vote if the date was included inside the changelog? If so, I'll re-roll
the release.

Stefan

On 2017-05-31, Maarten Coene wrote:

> Why not simply  ?That is the date 
> the vote started and the binaries were built?Or perhaps you could add a few 
> days to it and make sure the vote ends at that date?

> It's just strange when reading the documentation of a released version to see 
> that it's 'unreleased' or 'during-release'...

> Maarten


>   Van: "Matèrne, Jan (RZF, Ref 410)" 
>  Aan: Ant Developers List 
>  Verzonden: woensdag 31 mei 10:25 2017
>  Onderwerp: AW: [VOTE] Release Compress Antlib 1.5 based on RC1

> Maybe
> ?

> Jan

> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:bode...@apache.org]
> Gesendet: Mittwoch, 31. Mai 2017 09:46
> An: dev@ant.apache.org
> Betreff: Re: [VOTE] Release Compress Antlib 1.5 based on RC1

> On 2017-05-31, Maarten Coene wrote:

>> The changes.xml still contains the following line:> date="unreleased">
>> I'm not sure this should block the release, but I think it would be better 
>> to fill in the correct date.

> This is a chicken and egg problem. As long as the vote hasn't passed, I
> don't know the release date :-)

> Stefan

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

Re: Problems Releaseing Antlibs

[J Pai]

Just had a look at that ivysettings-nexus.xml file. You are right, changing 
that file should fix it.

-Jaikiran
On 31-May-2017, at 5:43 PM, Stefan Bodewig  wrote:

On 2017-05-31, J Pai wrote:

> These are the changes (which incorporates Gintas suggestion) that
> might help get us past the upload issue.

I've only modified ivysettings-nexus.xml obtained from common (locally,
not pushed, yet) and that seems to have done the trick. I didn't have to
change prepare-upload or upload.xml back from dots to slashes.

Thanks

   Stefan

-
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: Problems Releaseing Antlibs

[Stefan Bodewig]

On 2017-05-31, J Pai wrote:

> These are the changes (which incorporates Gintas suggestion) that
> might help get us past the upload issue.

I've only modified ivysettings-nexus.xml obtained from common (locally,
not pushed, yet) and that seems to have done the trick. I didn't have to
change prepare-upload or upload.xml back from dots to slashes.

Thanks

Stefan

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

Re: Problems Releaseing Antlibs

[J Pai]

These are the changes (which incorporates Gintas suggestion) that might help 
get us past the upload issue.

Change to ivy.xml of compress project:

diff --git a/ivy.xml b/ivy.xml
index eb034ac..6c5e823 100644
--- a/ivy.xml
+++ b/ivy.xml
@@ -18,7 +18,7 @@

 -->
 
-  
 
+  
value="${build.javarepository}/org/apache/ant/${artifact.name}/${artifact.version}"/>
 
 
 
diff --git a/upload.xml b/upload.xml
index d4910e6..a0165dc 100644
--- a/upload.xml
+++ b/upload.xml
@@ -35,7 +35,7 @@
 
 
 
   


Let us know if this doesn’t help.

-Jaikiran

On 31-May-2017, at 4:41 PM, Gintautas Grigelionis  
wrote:

Use different pattern [orgPath] rather than [organisation]

Gintas

http://ant.apache.org/ivy/history/latest-milestone/concept.html

2017-05-31 11:36 GMT+02:00 Stefan Bodewig :

> On 2017-05-31, Stefan Bodewig wrote:
> 
>> I'll fix common first (and update Ivy as I go, then fix Compress and
>> do a test deploy that I can easily drop again.
> 
> /devel/ASF/ant-antlibs-compress/common/upload.xml:40: impossible to
> publish artifacts for org.apache.ant#ant-compress;1.5.1:
> java.io.IOException: PUT operation to URL https://repository.apache.org/
> service/local/staging/deploy/maven2/org.apache.ant/ant-
> compress/ant-compress/1.5.1/ant-compress-1.5.1.pom failed with status
> code 400: Bad Request
> 
> I'm afraid Nexus doesn't like the organization. I just had a look at
> Ant's own ivy.xml[1]. It uses organisation="org/apache" (slashes rather
> than dots). I'll play with some variations later.
> 
> Stefan
> 
> [1] https://git-wip-us.apache.org/repos/asf?p=ant.git;a=blob;f=
> release/ivy.xml
> 
> -
> 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: Problems Releaseing Antlibs

[Gintautas Grigelionis]

Use different pattern [orgPath] rather than [organisation]

Gintas

http://ant.apache.org/ivy/history/latest-milestone/concept.html

2017-05-31 11:36 GMT+02:00 Stefan Bodewig :

> On 2017-05-31, Stefan Bodewig wrote:
>
> > I'll fix common first (and update Ivy as I go, then fix Compress and
> > do a test deploy that I can easily drop again.
>
> /devel/ASF/ant-antlibs-compress/common/upload.xml:40: impossible to
> publish artifacts for org.apache.ant#ant-compress;1.5.1:
> java.io.IOException: PUT operation to URL https://repository.apache.org/
> service/local/staging/deploy/maven2/org.apache.ant/ant-
> compress/ant-compress/1.5.1/ant-compress-1.5.1.pom failed with status
> code 400: Bad Request
>
> I'm afraid Nexus doesn't like the organization. I just had a look at
> Ant's own ivy.xml[1]. It uses organisation="org/apache" (slashes rather
> than dots). I'll play with some variations later.
>
> Stefan
>
> [1] https://git-wip-us.apache.org/repos/asf?p=ant.git;a=blob;f=
> release/ivy.xml
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: AW: [VOTE] Release Compress Antlib 1.5 based on RC1

[Maarten Coene]

Why not simply  ?That is the date the 
vote started and the binaries were built?Or perhaps you could add a few days to 
it and make sure the vote ends at that date?

It's just strange when reading the documentation of a released version to see 
that it's 'unreleased' or 'during-release'...

Maarten


  Van: "Matèrne, Jan (RZF, Ref 410)" 
 Aan: Ant Developers List  
 Verzonden: woensdag 31 mei 10:25 2017
 Onderwerp: AW: [VOTE] Release Compress Antlib 1.5 based on RC1
   
Maybe 
?

Jan

-Ursprüngliche Nachricht-
Von: Stefan Bodewig [mailto:bode...@apache.org] 
Gesendet: Mittwoch, 31. Mai 2017 09:46
An: dev@ant.apache.org
Betreff: Re: [VOTE] Release Compress Antlib 1.5 based on RC1

On 2017-05-31, Maarten Coene wrote:

> The changes.xml still contains the following line: date="unreleased">
> I'm not sure this should block the release, but I think it would be better to 
> fill in the correct date.

This is a chicken and egg problem. As long as the vote hasn't passed, I
don't know the release date :-)

Stefan

-
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 #37: Don't pollute the source lib folder during ivy retrieval ...

[twogee]

Github user twogee commented on the issue:

https://github.com/apache/ant-ivy/pull/37
  
Thanks, could this PR be merged? Then I'll clean up #36 


---
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: Problems Releaseing Antlibs

[Stefan Bodewig]

On 2017-05-31, Stefan Bodewig wrote:

> I'll fix common first (and update Ivy as I go, then fix Compress and
> do a test deploy that I can easily drop again.

/devel/ASF/ant-antlibs-compress/common/upload.xml:40: impossible to publish 
artifacts for org.apache.ant#ant-compress;1.5.1: java.io.IOException: PUT 
operation to URL 
https://repository.apache.org/service/local/staging/deploy/maven2/org.apache.ant/ant-compress/ant-compress/1.5.1/ant-compress-1.5.1.pom
 failed with status code 400: Bad Request

I'm afraid Nexus doesn't like the organization. I just had a look at
Ant's own ivy.xml[1]. It uses organisation="org/apache" (slashes rather
than dots). I'll play with some variations later.

Stefan

[1] https://git-wip-us.apache.org/repos/asf?p=ant.git;a=blob;f=release/ivy.xml

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

AW: [VOTE] Release Compress Antlib 1.5 based on RC1

[RZF, Ref 410]

Maybe 
?

Jan

-Ursprüngliche Nachricht-
Von: Stefan Bodewig [mailto:bode...@apache.org] 
Gesendet: Mittwoch, 31. Mai 2017 09:46
An: dev@ant.apache.org
Betreff: Re: [VOTE] Release Compress Antlib 1.5 based on RC1

On 2017-05-31, Maarten Coene wrote:

> The changes.xml still contains the following line: date="unreleased">
> I'm not sure this should block the release, but I think it would be better to 
> fill in the correct date.

This is a chicken and egg problem. As long as the vote hasn't passed, I
don't know the release date :-)

Stefan

-
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: Problems Releaseing Antlibs

[Stefan Bodewig]

On 2017-05-31, J Pai wrote:

> I had a brief look at this project’s repo and triggered these tasks
> locally. Of course, I won’t be able to test the whole upload process,
> but I was able to see what’s wrong.

Great!

> There are 2 “projects” that need this fix. The “common” project and
> the “compress” project. Here are the changes that were required for me
> to get past it:

Many thanks. I'll fix common first (and update Ivy as I go, then fix
Compress and do a test deploy that I can easily drop again. The same fix
required for Compress is probably needed for all other antlibs as well,
I'll take care of that.

The Antlibs are hibernating and so the build infrastructure hasn't been
kept up-to-date.

Thanks a lot

   Stefan

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

[GitHub] ant-ivy issue #36: Replace emma with jacoco

[jaikiran]

Github user jaikiran commented on the issue:

https://github.com/apache/ant-ivy/pull/36
  
>> I found out that JUnit tests polute run.classpath by placing an empty 
jar in /lib, which breaks eg javadoc. Any ideas which test may do that?

I believe this PR https://github.com/apache/ant-ivy/pull/37 will address 
that issue


---
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 #37: Don't pollute the source lib folder during ivy ret...

[jaikiran]

GitHub user jaikiran opened a pull request:

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

Don't pollute the source lib folder during ivy retrieval in test

The `IvyRetrieveBuildFileTest` triggers a Ant project build during the test 
case and issues a `ivy:retrieve` through the build file. The retrieve ends up 
putting these test files (some of which are dummy files) into the `${lib.dir}` 
of the project source and causes issues like the one noted in 
https://github.com/apache/ant-ivy/pull/36

>> I found out that JUnit tests polute run.classpath by placing an empty 
jar in /lib, which breaks eg javadoc. Any ideas which test may do that?

The commit in this PR fixes that issue to use a test build specific 
directory to retrieve these test specific artifacts.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jaikiran/ant-ivy lib-pollution

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ant-ivy/pull/37.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #37


commit cb91a10627d2e68bae924e425ad6f21353f5bf94
Author: Jaikiran Pai 
Date:   2017-05-31T07:43:28Z

Don't pollute the source lib folder during ivy retrieval in test




---
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: [VOTE] Release Compress Antlib 1.5 based on RC1

[Stefan Bodewig]

On 2017-05-31, Maarten Coene wrote:

> The changes.xml still contains the following line: date="unreleased">
> I'm not sure this should block the release, but I think it would be better to 
> fill in the correct date.

This is a chicken and egg problem. As long as the vote hasn't passed, I
don't know the release date :-)

Stefan

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