Re: JUnitTask - Question

Stefan Bodewig schrieb: > >>Generally this is okay for ANT because it seems that ANT creates the >>child-elements before setting the attributes, so this won't produce >>an error (correct me if I'm wrong). But I would like to know if >>this is part of ANT's design so a developer must take this in

Re: JUnitTask - Question

One can use the "configured" form of the add method. public void addConfiguredCommandline(Commandline c) { } Ant will set the attributes / elements on Commandline c before calling addConfiguredCommandline(Commandline c) Peter On 3/23/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > > On Tue, 14

Re: JUnitTask - Question

On Tue, 14 Mar 2006, Daniel Kasmeroglu <[EMAIL PROTECTED]> wrote: > Generally this is okay for ANT because it seems that ANT creates the > child-elements before setting the attributes, so this won't produce > an error (correct me if I'm wrong). But I would like to know if > this is part of ANT's

Re: on java1.5

On Thu, 23 Mar 2006, Steve Loughran <[EMAIL PROTECTED]> wrote: > Gump didnt want to move to java1.5; Well, Gump being what it is should be running Mustang beta by now. Not running 1.5 was mainly influenced by not havong one installed on vmgump and people not having time to install it. > junit fo

Re: on java1.5

On Thu, 23 Mar 2006, Steve Loughran <[EMAIL PROTECTED]> wrote: > Now that Gump has switched to java1.5, its showing up some problems > in javac. > > Specifically, it appears to be defaulting to source=1.5 Please take the time and look into the manual page of the task, in particular the bold-face

DO NOT REPLY [Bug 33260] - p4change task does not set p4.change property correctly

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bu

Re: on java1.5

> if we the properties ant._internal._javac.source and > ant._internal._javac.target that set the defaults for javac, then you > can also use them on the command line to build anything 'legacy', > without touching the build file. Even though someone could abuse these "Magic" properties for other p

Re: on java1.5

Perhaps this could be in the gump definition of a project? Peter On 3/23/06, Steve Loughran <[EMAIL PROTECTED]> wrote: > > Peter Reilly wrote: > > #1 would not be backwardly compatible ! > > > > I am not too sure about #2. In the ant build > > file we had to deal with this issue for a while, > >

Re: on java1.5

Peter Reilly wrote: #1 would not be backwardly compatible ! I am not too sure about #2. In the ant build file we had to deal with this issue for a while, it may be as well to get other project 1.5 aware. Also new projects would have to set things so that 1.5 (and higher) would work. Telling p

Re: on java1.5

#1 would not be backwardly compatible ! I am not too sure about #2. In the ant build file we had to deal with this issue for a while, it may be as well to get other project 1.5 aware. Also new projects would have to set things so that 1.5 (and higher) would work. Peter On 3/23/06, Steve Loughra

Re: on java1.5

> Now, when 's dependency logic broke moving up to 1.5, I fixed it > by forcing the proxy generation to be downwards compatible, so > everything behaved as on a 1.3 or 1.4 box. True, and was probably the right choice. But there are fewer users than users, so impacts less people. > Here are some

Re: on java1.5

Dominique Devienne wrote: Specifically, it appears to be defaulting to source=1.5 [...] I checked out the source in CVS; they are not saying source="1.5"; they are not saying anything about the source version. Yet javac has switched to java1.5. This is breaking backwards compatibility for builds.

Re: "No runnable method" exception during junit task with SVN HEAD and JUnit 4.

> The junit4 class doesn't know or care if there is a 'static Test suite()' > method on the class. It looks for Annotations, and then falls back on > pattern matching method names. It seems that the suite() method has always > been an Ant thing. I beg to differ. Honoring suite() methods has been

Re: on java1.5

> Specifically, it appears to be defaulting to source=1.5 > [...] > I checked out the source in CVS; they are not saying source="1.5"; they > are not saying anything about the source version. Yet javac has switched > to java1.5. This is breaking backwards compatibility for builds. It was always my

on java1.5

Now that Gump has switched to java1.5, its showing up some problems in javac. Specifically, it appears to be defaulting to source=1.5 This breaks junit addons http://vmgump.apache.org/gump/public/junit-addons/junit-addons/gump_work/build_junit-addons_junit-addons.html I checked out the sou

Re: Custom task and type documentation revisited

Curt Arnold wrote: I'm doing my annual cpptasks (http://ant-contrib.sourceforge.net) cleaning and expect to be producing long overdue release shortly and hopefully additional releases at more reasonable intervals. The current cpptasks build uses tools from the proposals/xdocs to generate raw

Re: "No runnable method" exception during junit task with SVN HEAD and JUnit 4.

Bill Barker wrote: "Curt Arnold" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] On Mar 20, 2006, at 12:39 PM, Jesse Glick wrote: Curt Arnold wrote: when Ant auto-detects JUnit-4, it doesn't look for the static suite() method, and just assumes that you've defined all of your test