I think this new task should be part of Ant, because it difficult with Ant 1 to install a new task (no dynamic load), I hope the problem will be resolve with Ant 2, and I'm sure there are more Python developers than dotNet developers ! Example : <jythonc home="/usr/jython-2.1/" srcdir="${src}" > <include name="*.py" /> <exclude name="Test.py" /> </jythonc> Sorry no unit-test, but I can't run unit-test without a correct Jython installation.
Created attachment 1565 [details] WHATSNEW, optionaltasklist.html, defaults.properties
Created attachment 1566 [details] jakarta-ant\src\main\org\apache\tools\ant\taskdefs\optional\python\Jythonc.java
Created attachment 1567 [details] jakarta-ant\docs\manual\OptionalTasks\python.html
Just to clarify: what is so difficult about using <taskdef> in Ant 1.x? Why is having this part of Ant much different than having this task available with Jython with an example <taskdef>?
A few points. 1. "No dynamic load" - have you looked at the taskdef task? Perhaps you mean "No auto load". 2. I would suggest not extending MatchingTask. Instead it would be preferable to provide support for filesets with an addFileset() method. 3. I'm not sure I understand the issue with unit tests? Cheers
<taskdef> is not cool because you have to download a JAR file, put in a directory, and add <taskdef> in your build file without syntax error. If you want to distribute your build file, you must not forget to give the JAR file. Yes I would mean "auto load". Ant is a great tool, but a lot of junior developers prefer to use the one button click of JBuilder (or worst VStudio). Ant must progress in its installation and configuration process. > I would suggest not extending MatchingTask. I don't understand why. You don't like it ?
Hmm, two lines of code per build file, versus the support and maintenance we'd have to add but wait a minute, you need jython anyway right? So stick the JAR in your own SCM system (like in lib) <taskdef resource="org.someone.jythontask.properties classpath="lib/jythonant.jar;lib\jython.jar"> And all is well. FYI we are trying to move away from putting everything in optional.jar and move to a world where we can load stuff from jars more easily; once that is done we can break up optional jar into pieces anyway. Adding more tasks to ant just adds diversionary work. In particular, for other open source projects we like the tasks to go with the projects themselves, if at all possible. Can you get the jython people to take this task on board? Then all you need is jython.s own jar.
I support Steve arguments, this task is in a better place in Jython ...would it be for a simple maintenance and support reason.
*** Bug 18363 has been marked as a duplicate of this bug. ***