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