Some years ago there were a discussion about having ant-contrib a part of Ant.
Result was that it wasn't possible due IP (and therefore legal) reasons.
Having a look at the tasklist [1] there are some I would use:
* antcallback: maybe enhance <antcall>
* antfetch: maybe (same base idea as antcallback)
* assert: not required, you could use antunit
* foreach: no in favour of 'for'
* for: yep
* if: not required since xmlns:if is available
* outofdate: no idea
* runtarget: no: use <ant> or <macrodef> or <antcall>
* switch: maybe, but would be in contra to <if>, you could use <antcall
target="prefix${value}">
* throw: no, maybe enhance <fail>
* timetstampselector: no; nice idea but I would investigate more in using
resource collections and all existing selectors, not only the tstamp one
* trycatch: maybe
* httppost: yep
* antserver: no
* performancemonitor: no, use ProfileLogger [2]
* stopwatch: no, use [2]
* osfamily: use <os> condition
* shellscript: use <script>
* math: unsure, why do you want to calculate in a buildfile? (small
calculations can be done with <propertyfile>)
* propertycopy: maybe we should promote the props antlib [3] ...
* propertyselector: no
* pathtofileset: unsure
* propertyregex: maybe, but maybe I also should have a deeper look into
props-antlib
* sortlist: no
* urlencode: maybe
* variable: no, you may use <local> in a <macrodef>
* forget: no, exec+spawn
* limit: unsure; the timeout for long-running tests is done on the CI server
these days
* antclipse: no (unstable)
* compilewithwalls: no (deprecated)
* inifile: maybe (primarily use outside the java world? do we need a <registry>
task? A windows-antlib?)
* verifydesign: unsure; a breaking build would be a clear signal; but tools
like SonarQube and all the architectural tools (I should have a look at ;) are
much more powerful than this
Jan
[1] http://ant-contrib.sourceforge.net/tasks/tasks/index.html
[2] http://ant.apache.org/manual/listeners.html#ProfileLogger
[3] http://ant.apache.org/antlibs/props/index.html
> -----Ursprüngliche Nachricht-----
> Von: Gintautas Grigelionis [mailto:g.grigelio...@gmail.com]
> Gesendet: Montag, 5. Juni 2017 06:22
> An: Ant Developers List; Paul King
> Betreff: Re: Ant Contrib
>
> Jan was having a problem with JaCoCo last week because of multiple
> copies of ASM library on the classpath because he was building both Ant
> and Ivy in the same workspace. He mentioned making some checks on the
> contents of the classpath. I thought it was appropriate to remind of a
> solution that was proposed 12 years ago :-)
>
> Gintas
>
> 2017-06-05 6:16 GMT+02:00 Paul King <pa...@asert.com.au>:
>
> > On Sun, Jun 4, 2017 at 7:47 PM, Gintautas Grigelionis <
> > g.grigelio...@gmail.com> wrote:
> >
> > > [...]
> > > P.S. While we're at it, in the light of the latest ASM debacle, I'm
> > > interested in improving Ant classloader task
> >
> > [...]
> >
> >
> > Which ASM issue(s) are you referring to? Is there a link to some
> > discussions?
> >
> > Cheers, Paul.
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
