Re: JUnit4 requirement (was Re: svn commit: r1460264)
Hi, I have noticed a bug report CASSANDRA-5388 concerning Ant 1.9.0 and JUnit library dependencies. Maybe this bug report can help to clarify the exact dependencies of Ant concerning JUnit. The current install.html in svn says that Ant is dependent upon junit.jar without specifying minimal versions and without differentiating between junit3 and junit4. It would help if someone would explain the dependency in more detail. Regards, Antoine On Mar 30, 2013, at 2:44 PM, Stefan Bodewig wrote: On 2013-03-28, Stefan Bodewig wrote: On 2013-03-27, Michael Clarke wrote: * the optional ant-junit4.jar has been merged into ant-junit.jar as Ant now requires JUnit4. Is it really the case that Ant requires JUnit4? The changes I introduced for @Ignore annotations in Ant 1.9.0 shouldn't impact backwards compatibility with JUnit3 and I don't believe any other changes in the 1.9.0 release force users to need the JUnit4 jar whilst running tests. Some classes in the junit package didn't seem to compile in Gump, I think BriefJUnitFormatter was one of them. The formatter all now import org.junit.Ignore so require JUnit 4 at compile time. It may stil be possible to use JUnit 3 at runtime. 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
manual on the web site
Hi, the manual on the web site is currently the manual of Ant 1.8.2, in principle the manual of Ant 1.9.0 should be displayed. I believe the manual is correct in subversion under http://svn.apache.org/repos/asf/ant/site/ant/production/ and http://svn.apache.org/repos/asf/ant/site/ant/sources/ So I am bugging our infra with https://issues.apache.org/jira/browse/INFRA-6228 Regards, Antoine
Re: Adding if/unless conditions on commandline args
wow, I had forgot about that!
Peter
On Mon, May 6, 2013 at 12:55 AM, Antoine Levy Lambert anto...@gmx.dewrote:
Hi,
I have committed a patch created by Peter Reilly back in 2007.
The bugzilla PR is 43362 [1]
If the community is happy with this change we will be able to close a
number of bug reports requesting if/unless on various elements .
For instance 49136 requesting if/unless support for attribute nested
element of manifest task,
49036 add 'unless' attribute to JUnit test element,
...
Regards,
Antoine
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43362
On May 3, 2013, at 5:37 AM, Jan Matèrne (jhm) wrote:
AFAIK this was discussed several times in the past (few years) with the
result, that having if/unless an _all_ elements would decrease
maintainability of the build scripts.
But +1 from me for having if/unless on nested elements.
What about supporting more complex conditions via nested condition
elements?
Jan
-Ursprüngliche Nachricht-
Von: Michael Clarke [mailto:michael.m.cla...@gmail.com]
Gesendet: Freitag, 3. Mai 2013 11:01
An: Ant Developers List
Betreff: Re: Adding if/unless conditions on commandline args
+1 from me too
On 3 May 2013, at 09:37, Jean-Louis Boudart
jeanlouis.boud...@gmail.com wrote:
+1
2013/5/3 Antoine Levy Lambert anto...@gmx.de
I wonder whether we could not add if an unless on all nested
elements
in the framework ?
Regards,
Antoine
On May 3, 2013, at 2:57 AM, Jean-Louis Boudart wrote:
Hi,
It's currently difficult to make reusable script when using exec
task
or
any other task using commandline args.
We oftenly need some dynamic arguments and this can be
complicated.
Therefor, i suggest to introduce if/unless conditions on comand
line
args :
exec executable=git
arg value=commit/
arg line=-a if=${commit.all.files}/ arg value=-m/ arg
value=${commit.message}/ /exec
I have a working implementation with related tests and
documentation.
Commandline.Arg class now extends ProjectComponent, and expose
accessors for if/unless condition, and rely on PropertyHelper to
check conditions.
Is this sufficient ? From what i have seen, it doesn't break
backward compatibility at least all tests are green :p.
The setProject(Project p) method should be invoked automatically
by ProjectHelper isn't it ?
If ant is used in pure java and we ommited invoking
setProject(Project p) method, it should also works as
PropertyHelper seems null safe.
If there is no objection i will commit this this week end.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
additional
commands, e-mail: dev-h...@ant.apache.org
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/
-
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: Evaluating Bintray as a distribution platform for easyant plugins
No objections from me. Antoine On May 3, 2013, at 6:04 AM, Jean-Louis Boudart wrote: No objections either if both Apache non Apache plugins are on bintray ? :p 2013/5/3 Jan Matèrne (jhm) apa...@materne.de Neither from me. My objections were for ASF plugins not for outside ASF ;) Jan -Ursprüngliche Nachricht- Von: Antoine Levy Lambert [mailto:anto...@gmx.de] Gesendet: Freitag, 3. Mai 2013 10:06 An: Ant Developers List Betreff: Re: Evaluating Bintray as a distribution platform for easyant plugins Hello Jean-Louis, I was not aware of bintray, I have just looked at the web site. No objections from me. Regards, Antoine On May 3, 2013, at 2:14 AM, Jean-Louis Boudart wrote: No objections? :p Le 29 avr. 2013 20:59, Jean-Louis Boudart jeanlouis.boud...@gmail.com a écrit : Here is the original thread from easyant-dev ML during apache incubation : http://markmail.org/thread/uv2xkj63rkdh2thh Le 29 avr. 2013 20:53, Jean-Louis Boudart jeanlouis.boud...@gmail.com a écrit : I would prefer having the artifacts on ASF servers. A (Nexus based) repository is at https://repository.apache.org/ Ant + Ivy are available at https://repository.apache.org/content/repositories/releases/ I would also prefer this but will ASF authorize non apache project (read plugins with incompatible licences for example) to publish there ? I don't think so. By the way you really got the idea, have one connection point to ease understanding for the community. That's why we intially setup a online repository (repo.easyant.org) with two internal repository : * one for apache plugins * one for non apache plugins (the one having potential issues with licenses like sonar or checkstyle) I was suggesting to reproduce this on bintray. If this could be done @ASF i would definitively go in that direction ! But is this really possible ? As bintray and github supports Markdown syntax, i made some experimentation on plugin documentation generation. Are you writing the markdown by hand or do you generate that from java source? Generated through easyant plugin report task ( http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant- pl ugin-documentation/src/main/resources/easyant-report-mardown.xsl) with a custom xsl ( http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant- pl ugin-documentation/src/main/resources/easyant-report-mardown.xsl ) Result on github : https://github.com/easyant/sonar-easyant- plugin Result on bintray : https://bintray.com/pkg/show/readmore/easyant/community- plugins/sona r- easyant-plugin On BinTray the tables are broken. No syntax highlighting on BT? I also reported this. Git support is growing at ASF, e.g. Camel is on the migration path from svn to git. A blocker to their vote is https://issues.apache.org/jira/browse/INFRA-6197 Nice to know :). I was talking here for non apache plugins/ - 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 -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/ - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JUnit4 requirement (was Re: svn commit: r1460264)
Ant 1.9.0 contained 2 issues relating to JUnit 4: 1. Ant not compiling if only JUnit 3 was on the classpath. This was discussed as part of this mail thread and resolved with SVN commit 1471109. There shouldn't have been any direct impact on users as it wasn't possible to invoke any of the code that would have thrown class not found exceptions without a unit tests having thrown an AssumptionViolatedException from the JUnit 4 JAR. 2. NoClassDefFoundError if attempting to use a JUnit JAR outside of the Ant lib directory (Bug 54835). This would impact any user who is defining the JUnit JAR in the classpath property for the JUnit task but not having the JAR in Ant's classpath (any user using Ant without adding additional JARs to ANTLIB and using Ivy or Maven tasks to download the JUnit JAR). This was fixed in SVN commit 1470668 by updating the list of classes to be handled by the split class loader. The basic outcome of this is that there is no requirement for a specific version of JUnit for anyone running the JUnit task, but version 1.9.0 of Ant does require JUnit (the version shouldn't matter) to be on the core classpath. We could update the documentation to specify that any version of JUnit 3 or 4 could be placed on the classpath, providing it satisfies the dependencies in the user's code, but there is no need to specify a specific version of JUnit in our documentation. Thanks, Michael On 6 May 2013, at 10:01, Antoine Levy Lambert anto...@gmx.de wrote: Hi, I have noticed a bug report CASSANDRA-5388 concerning Ant 1.9.0 and JUnit library dependencies. Maybe this bug report can help to clarify the exact dependencies of Ant concerning JUnit. The current install.html in svn says that Ant is dependent upon junit.jar without specifying minimal versions and without differentiating between junit3 and junit4. It would help if someone would explain the dependency in more detail. Regards, Antoine On Mar 30, 2013, at 2:44 PM, Stefan Bodewig wrote: On 2013-03-28, Stefan Bodewig wrote: On 2013-03-27, Michael Clarke wrote: * the optional ant-junit4.jar has been merged into ant-junit.jar as Ant now requires JUnit4. Is it really the case that Ant requires JUnit4? The changes I introduced for @Ignore annotations in Ant 1.9.0 shouldn't impact backwards compatibility with JUnit3 and I don't believe any other changes in the 1.9.0 release force users to need the JUnit4 jar whilst running tests. Some classes in the junit package didn't seem to compile in Gump, I think BriefJUnitFormatter was one of them. The formatter all now import org.junit.Ignore so require JUnit 4 at compile time. It may stil be possible to use JUnit 3 at runtime. 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
