Sounds fine to me.
-Jaikiran
On 04/06/18 1:08 PM, Stefan Bodewig wrote:
Hi all
one of the recurring issues that make Jenkins builds fail is a
thread-safety bug in AntUnit's log capturing code. This is supposed to
be fixed in AntUnit's master branch.
I propose to build an alpha version of Ant
Looks like Ant-Build-Matrix is finally fixed! I have reenabled mail sent to
notificati...@ant.apache.org so we can track regressions.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev
Le 9 avr. 2012 à 07:35, Stefan Bodewig a écrit :
> Hi,
>
> by now I've managed to reduce the number of failing tests to 0 on two of
> the six build configurations. What remains:
>
> * a failure that only happens on Java5 machines WRT a closed ZIP. I'll
> re-investigate what is going on here
On 2012-02-24, Jesse Glick wrote:
> On 02/24/2012 12:12 AM, Stefan Bodewig wrote:
>> It is supposed to be used via ./build.sh antunit-tests.
> Ah. But when I do that, I get failures that I do not get when I use
> ./dist/bin/ant -lib lib/optional antunit-tests, e.g.:
> Build File: .../src/tests/a
On 02/24/2012 12:12 AM, Stefan Bodewig wrote:
It is supposed to be used via ./build.sh antunit-tests.
Ah. But when I do that, I get failures that I do not get when I use
./dist/bin/ant -lib lib/optional antunit-tests, e.g.:
Build File: .../src/tests/antunit/bugfixes/br50866/br50866-test.xml
T
On 2012-02-23, Jesse Glick wrote:
> ...though it hangs in taskdefs/exec/apply-test.xml:
I've never seen it hang but some of the exec tests fail for me regularly
as well (as they occasionaly do on Gump).
Stefan
-
To unsubscribe,
On 2012-02-23, Jesse Glick wrote:
> On 02/23/2012 04:09 PM, Jesse Glick wrote:
>> $ ant -lib lib/optional/ant-antunit-1.2.jar antunit-tests
> Never mind, just figured out that you need to use
> $ ./dist/bin/ant ...
> to actually test trunk code! Maybe build.xml should detect this
> somehow and
...though it hangs in taskdefs/exec/apply-test.xml:
apply-test.antunit:
Build File: .../src/tests/antunit/taskdefs/exec/apply-test.xml
...
"main" prio=10 tid=0x091c7c00 nid=0x24e0 in Object.wait() [0xf6947000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait
On 02/23/2012 04:09 PM, Jesse Glick wrote:
$ ant -lib lib/optional/ant-antunit-1.2.jar antunit-tests
Never mind, just figured out that you need to use
$ ./dist/bin/ant ...
to actually test trunk code! Maybe build.xml should detect this somehow and
warn you (though of course it would be bette
Hi,
this is reproducible on a Mac under JDK 1.6.0 like this
export ANT_OPTS=-Xbootclasspath/p:../../../opt/xerces-2_9_1/xercesImpl.jar
./build.sh -Dtest.haltonfailure=false -Dbuild.sysclasspath=only
-Dtestcase=core/classloader-test.xml run-tests
the antunit test file core/classloader-test.xml
Le 21 oct. 09 à 07:32, Stefan Bodewig a écrit :
On 2009-10-17, Nicolas Lalevée wrote:
I have some use case where I need to fail no matter what. Basically I
need a task corresponding to the junit.framework.Assert#fail().
To implement it I suggest we implement it like the fail Ant
task. Act
On 2009-10-17, Nicolas Lalevée wrote:
> I have some use case where I need to fail no matter what. Basically I
> need a task corresponding to the junit.framework.Assert#fail().
> To implement it I suggest we implement it like the fail Ant
> task. Actually I suggest to rename "assertTrue" to "fail
On Fri, 22 Aug 2008, Peter Reilly <[EMAIL PROTECTED]> wrote:
> sounds good
OK, so if I start the release process I may in the end actually find
three people who'll vote on it 8-)
I volunteer to be the release manager and will probably put together a
beta release next week.
> (am catching up on
sounds good (am catching up on my e-mail queue).
Peter
On Tue, Jul 15, 2008 at 1:58 PM, Kevin Jackson <[EMAIL PROTECTED]> wrote:
>> ant's trunk has been using a snapshot of AntUnit's trunk for quite
>> some time now, so we seem to need some unreleased feature. How about
>> making it available t
> ant's trunk has been using a snapshot of AntUnit's trunk for quite
> some time now, so we seem to need some unreleased feature. How about
> making it available to others as well?
Sounds reasonable.
Kev
-
To unsubscribe, e-mai
On Fri, 30 Nov 2007, David Jackman <[EMAIL PROTECTED]>
wrote:
> I've made several enhancement requests for AntUnit [1].
I for one have pretty busy in the past month (seems I'm saying this
pretty often), so I didn't pay attention to bugzilla at all.
> They all include patches (and all the patches
Hi,
> I see you've applied the patch I submitted for a bug I wrote up on AntUnit
> (bug
> 43466--http://issues.apache.org/bugzilla/show_bug.cgi?id=43466).
Yes, I'm trying to close out issues on bugzilla right now.
> I have some other enhancements that I'll be writing up in Bugzilla in the
> com
Steve had a similar case once, I vaguely recall it was related to
forking during the tests, but may be wrong.
What have your tests been doing?
The test was the one for (which may be refactored
to a macro based on Matt's feedback)
So it was simply comparing if a resource contained a substring
On Sat, 12 May 2007, Kevin Jackson <[EMAIL PROTECTED]> wrote:
> Just writing some antunit tests for a new condition and got this in
> the output:
>
> [antunit] took 1,178,948,204.551 sec
>
> That's a long time!
so to answer the question in your subject: yes, the timing is not
quite exact,
> -Original Message-
> From: Kevin Jackson [mailto:[EMAIL PROTECTED]
> Sent: Saturday, 12 May 2007 3:08 PM
> To: Ant Developers List
> Subject: Antunit timings inaccurate?
>
> Hi all,
>
> Just writing some antunit tests for a new condition and got
> this in the output:
>
> [antuni
On Fri, 22 Dec 2006, Martijn Kruithof <[EMAIL PROTECTED]> wrote:
> Not only that our testsuite of 1.7.0 final relies on it so
> definetely +1 here.
OK, that have been +1s by plenty of people by now. I'll build release
tarballs sometime latr this week/early next week so that we can vote
on them a
: Fri, 22 Dec 2006 18:27:08 +
Von: "Peter Reilly" <[EMAIL PROTECTED]>
An: "Ant Developers List"
Betreff: Re: AntUnit
On 12/22/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
On Thu, 21 Dec 2006, Peter Reilly <[EMAIL PROTECTED]> wrote:
Hi,
I have not done anything much with antunit yet, but I am also +1.
It is a cool way of testing ant tasks.
Regards,
Antoine
Original-Nachricht
Datum: Fri, 22 Dec 2006 18:27:08 +
Von: "Peter Reilly" <[EMAIL PROTECTED]>
An: "Ant Developers List"
On 12/22/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
On Thu, 21 Dec 2006, Peter Reilly <[EMAIL PROTECTED]> wrote:
>> > I haven't seen anybody complain about missing
>> > features in beta2, is
>> > AntUnit ready for a 1.0 release?
>
> Does it work with ant 1.6.5?
Not at all. Apart from relyin
On Thu, 21 Dec 2006, Peter Reilly <[EMAIL PROTECTED]> wrote:
>> > I haven't seen anybody complain about missing
>> > features in beta2, is
>> > AntUnit ready for a 1.0 release?
>
> Does it work with ant 1.6.5?
Not at all. Apart from relying on ResourceCollections it uses a bunch
of other API ch
On 12/20/06, Matt Benson <[EMAIL PROTECTED]> wrote:
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Wed, 20 Dec 2006, Steve Loughran
> <[EMAIL PROTECTED]> wrote:
>
> > Does this also means we can go to 1.0 with
> ?
>
> Do we want to?
>
> I haven't seen anybody complain about missing
> feature
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Wed, 20 Dec 2006, Steve Loughran
> <[EMAIL PROTECTED]> wrote:
>
> > Does this also means we can go to 1.0 with
> ?
>
> Do we want to?
>
> I haven't seen anybody complain about missing
> features in beta2, is
> AntUnit ready for a 1.0 release?
On 10/17/06, Antoine Levy-Lambert <[EMAIL PROTECTED]> wrote:
Stefan Bodewig wrote:
>
> If not I'll build new beta releases and call for a vote on them later
> this week.
>
> Stefan
>
>
+1
+1
Peter
Good morning Europe,
Antoine
--
On Wed, 11 Oct 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> Okay--looks like it's because the jars that contain
> the matcher impls aren't added to forked junit.
> Furthermore, as some of you are probably aware, it's
> been this way pretty much ever since the Ant jars were
> broken up. Looks l
Stefan Bodewig wrote:
>
> If not I'll build new beta releases and call for a vote on them later
> this week.
>
> Stefan
>
>
+1
Good morning Europe,
Antoine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
--- Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Matt Benson <[EMAIL PROTECTED]> wrote:
>
> > When I run the antunit tests against core HEAD, I
> > get
> > failures on the matcher stuff due to the
> > org.apache.tools.ant.util.regexp.Jdk14RegexpRegexp
> > class not being found. For some reason t
--- Matt Benson <[EMAIL PROTECTED]> wrote:
> When I run the antunit tests against core HEAD, I
> get
> failures on the matcher stuff due to the
> org.apache.tools.ant.util.regexp.Jdk14RegexpRegexp
> class not being found. For some reason this happens
> even when I set ant.regexp.matcherimpl to e.
On Thu, 5 Oct 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> You mention that properties, etc. are low-cost enough
> for setup; obviously so. My concern was actually for
> compilation of support classes (e.g. testing );
> I would hate to keep compiling and blowing away a
> bunch of classes in eac
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Oct 2006, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> > The AntUnit documentation says:
> >
> > "Each test target is run in a fresh Ant project;
> i.e.
> > each test target has a fresh set of properties and
> > references."
>
> I think it
On Tue, 3 Oct 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> The fun part: if we change the behavior to suit the
> documentation, the utility of beforeTests/afterTests
> is pretty much reduced to filesystem artifacts.
Or other expensive set up code like preparing a database or starting
an applica
On Tue, 3 Oct 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> The AntUnit documentation says:
>
> "Each test target is run in a fresh Ant project; i.e.
> each test target has a fresh set of properties and
> references."
I think it should better be the way the documentation says, even
though it is
Matt Benson wrote:
The AntUnit documentation says:
"Each test target is run in a fresh Ant project; i.e.
each test target has a fresh set of properties and
references." But if I have test targets:
one will fail, as I would expect given
The AntUnit documentation says:
"Each test target is run in a fresh Ant project; i.e.
each test target has a fresh set of properties and
references." But if I have test targets:
one will fail, as I would expect given that the
AntUnit code
Hmm... sounds reasonable. ;) -Matt
--- Peter Reilly <[EMAIL PROTECTED]> wrote:
> before/afterTests?
>
> Peter
>
>
> On 10/3/06, Dominique Devienne <[EMAIL PROTECTED]>
> wrote:
> >
> > On 10/3/06, Matt Benson <[EMAIL PROTECTED]>
> wrote:
> > > JUnit 4 and TestNG have a Before/AfterClass
> conce
before/afterTests?
Peter
On 10/3/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
On 10/3/06, Matt Benson <[EMAIL PROTECTED]> wrote:
> JUnit 4 and TestNG have a Before/AfterClass concept
> for expensive setup/tearDown applicable to most or all
> of a test class. AntUnit needs something simi
On 10/3/06, Matt Benson <[EMAIL PROTECTED]> wrote:
JUnit 4 and TestNG have a Before/AfterClass concept
for expensive setup/tearDown applicable to most or all
of a test class. AntUnit needs something similar;
e.g. before/after[File|Build|Resource|All]... I think
it's useful to retain the before/a
On Tue, 26 Sep 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> When writing antunit tests, one cannot use the
> log-inspection assertions or the new au:logcontent
> resource outside the context of an AntUnit test. This
> is understandable/unavoidable,
Is it? We could add a task that registers a
Hopefully you get the idea.
Uh, not really ;-)
How crazy is this?
Not crazy to me, because I implemented this once in the past on top of
JUnit (if I half-undertood you). I had a custom TestRunner that
accepted an additional -m testMethod switch. It slowly died when the
new version of JUnit c
Forgive the top post. In case anybody hasn't figured
it out, with Ant 1.7 beta 2 out the door and a new
AntUnit 1.0 beta apparently hot on its heels, I am
working on modifying the Ant core build to run both
junit and antunit tests... just to make sure nobody's
duplicating work. I am basically do
Forgive the top post. In case anybody hasn't figured
it out, with Ant 1.7 beta 2 out the door and a new
AntUnit 1.0 beta apparently hot on its heels, I am
working on modifying the Ant core build to run both
junit and antunit tests... just to make sure nobody's
duplicating work. I am basically doi
On Thu, 14 Sep 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> I didn't think of the *-support.xml case, that would
>> need to be added.
>
> This is the only contention area, then.
Wouldn't call it contention. I just didn't think of the case where
Trying to resend, since bounced. --DD
On 9/14/06, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> DD opined he would
> prefer INcluding **/*-test.xml , **/*Test.xml , or
> some other known pattern to excluding support files.
> My rationale is that I expect the majority of files
> under src/test
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Sep 2006, Matt Benson
> <[EMAIL PROTECTED]> wrote:
> integrate antunit tests into Ant core until
> after
> > 1.7's release, or can we go ahead and start
> > adding/migrating au tests?
>
> 1.7beta would be enough for me, but we'd also need
Stefan Bodewig wrote:
Hi,
as I stated in another thread, I don't feel bad for extending
ConditionBase but if a majority here would prefer AsserTask to stick
with a simple add(Condition) in a task derived class, I'd be up for it
as well. I'd only want to see this straightened out before we relea
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> Hi,
>
> as I stated in another thread, I don't feel bad for
> extending
> ConditionBase but if a majority here would prefer
> AsserTask to stick
> with a simple add(Condition) in a task derived
> class, I'd be up for it
> as well. I'd only want to
(1) Would you prefer a version of AssertTask that didn't extend
ConditionBase?
Yes.
(2) Would you want AntUnit to silently typedef all existing conditions
into the AntUnit namespace? People wouldn't even notice.
Yes, and no...
Yes, I'd prefer it only had a add(Condition), but doing (
It should extend ConditionBase.
On 9/13/06, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
Hi,
as I stated in another thread, I don't feel bad for extending
ConditionBase but if a majority here would prefer AsserTask to stick
with a simple add(Condition) in a task derived class, I'd be up for it
a
On Tue, 5 Sep 2006, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> Although I'm curious to know how this chicken-and-egg thing is
> resolved in Gump.
We build a minimal Ant without running the tests, then we build JUnit
with that version of Ant, then we build Ant again. To make things
more diff
On Tue, 5 Sep 2006, Matt Benson <[EMAIL PROTECTED]> wrote:
> Antunit depends on HEAD. So theoretically antunit
> can't be used in the wild until 1.7 is released (let's
> assume "in the wild" means released components only).
> Do we want to play by these rules ourselves and wait
> to integrate ant
Original-Nachricht
Datum: Tue, 5 Sep 2006 13:44:52 -0500
Von: "Dominique Devienne" <[EMAIL PROTECTED]>
An: "Ant Developers List"
Betreff: Re: antunit integration
Hello Dominique,
> Although I'm curious to know how this chicken-and-egg thing i
> But I'm more worried about the bootstrapping issue,
This chicken-and-egg issue was discussed before; I am
unfortunately too lazy to go find it in the archives,
but the answer was that Ant does not bootstrap antunit
to run its own tests; rather a built antunit is used
with Ant in pretty much the
--- Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > xmlns:au="antlib:org.apache.ant.antunit">
> > > includes="**/*.xml"
> > excludes="**/*-support.xml" />
> > <...listener... />
> >
> >
> > I excluded *-support.xml because I thought there
> might
> > be a need for support
<...listener... />
I excluded *-support.xml because I thought there might
be a need for support xml files (hopefully that was
obvious), and I selected a straightforward convention.
What modifications to this strategy do others
advocate?
I've always used **/test/*Test.class for JUnit tests (b
Stefan Bodewig wrote:
On Mon, 05 Jun 2006, Steve Loughran <[EMAIL PROTECTED]> wrote:
what is the release status of Antunit? Is is formally released?
No.
I intend to propose release plans for AntUnit and the .NET Antlib as
soon as Ant 1.7 is on the way.
ok. I've just started making use of
Couldn't you use a Selector for this?
Jose Alberto
> -Original Message-
> From: Dale Anson [mailto:[EMAIL PROTECTED]
> Sent: 08 November 2005 16:06
> To: Ant Developers List
> Subject: Re: AntUnit
>
>
>
> Stefan Bodewig wrote:
>
> >
> >
Stefan Bodewig wrote:
Might just need an "add(AntUnit)" method in AntUnit itself.
Interesting idea.
3. a way to disable individual tests or disable entire suites.
In JUnit I tend to do so by simply changing the name of the method
(prefix with no) and even in NUnit which s
On Mon, 07 Nov 2005, Dale Anson <[EMAIL PROTECTED]> wrote:
> There are a few things I'd like to see added to AntUnit:
>
> 1. better reporting, probably just need a more involved
> AntUnitListener.
Yes, this should be doable. The PlainListener really only is a first
start so I could see the resu
On Mon, 7 Nov 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> The current version of AntUnit probably has 80% or
> better of the total test functionality. I think our
> tests rely less and less on log messages and more on
> results, etc. Log contents are probably the biggest
> thing missing from
As I mentioned in another thread, this approach to unit testing for Ant
is much easier than junit testing. The concept is similar, but there is
no need to write Java code for tests. The tests are in build files,
several layers of indirection are avoided, and anyone who can write a
build file
--- Martijn Kruithof <[EMAIL PROTECTED]> wrote:
> Stefan Bodewig wrote:
>
> >I'd not be opposed against making antunit part of
> the core, but so far
> >it hasn't attracted enough committers to even leave
> the sandbox. And
> >the six months probation time is over, BTW.
FWIW, my feeling is that
Kev Jackson wrote:
I think the using / maintaining by ourselves is more of a chicken and
egg problem
- We do not really need it for our "outside ant" activities
- We cannot really use it for our "inside ant" activities as it is in
the sandbox.
- We do not maintain it as we do not use it, a
I think the using / maintaining by ourselves is more of a chicken and
egg problem
- We do not really need it for our "outside ant" activities
- We cannot really use it for our "inside ant" activities as it is in
the sandbox.
- We do not maintain it as we do not use it, and it is in the sand
Stefan Bodewig wrote:
I'd not be opposed against making antunit part of the core, but so far
it hasn't attracted enough committers to even leave the sandbox. And
the six months probation time is over, BTW.
Stefan
I think the using / maintaining by ourselves is more of a chicken and
egg p
On Fri, 4 Nov 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> --- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> Simply make the presence of antunit a requirement just as we
>> require junit today.
>
> So it could be fetched in some way similar to that
> done by fetch.xml ...
I was more thinking al
Matt Benson wrote:
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
Does it need to? Ant doesn't know where to get
junit either. Simply
make the presence of antunit a requirement just as
we require junit
today.
So it could be fetched in some way similar to that
done by fetch.xml ...
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Nov 2005, Matt Benson
> <[EMAIL PROTECTED]> wrote:
>
> > How does Ant know where to get antunit? From SVN?
>
>
> Does it need to? Ant doesn't know where to get
> junit either. Simply
> make the presence of antunit a requirement just a
Matt Benson wrote:
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
After bootstrapping, yes. There is no circular
dependency since you
don't need antunit to build Ant, only to test it.
How does Ant know where to get antunit? From SVN?
Using what? The svn antlib? How does Ant know w
On Wed, 2 Nov 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> How does Ant know where to get antunit? From SVN?
Does it need to? Ant doesn't know where to get junit either. Simply
make the presence of antunit a requirement just as we require junit
today.
Stefan
--
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Nov 2005, Matt Benson
> <[EMAIL PROTECTED]> wrote:
>
> > Again, I am anxious to get all of Ant's tests
> migrated
> > to Antunit,
>
> I'm not sure whether "all" is the best goal, but a
> lot of them can be.
> Looking over the tests I've a
On Wed, 2 Nov 2005, Matt Benson <[EMAIL PROTECTED]> wrote:
> Again, I am anxious to get all of Ant's tests migrated
> to Antunit,
I'm not sure whether "all" is the best goal, but a lot of them can be.
Looking over the tests I've added over the past weeks, I really only
needed antunit's capabiliti
--- Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> On Tue, 01 Nov 2005, Dale Anson
> <[EMAIL PROTECTED]> wrote:
>
> > A quick google found them in the Ant Sandbox area
> as AntUnit. Would
> > it be acceptable to submit a patch to a core task
> that included a
> > unit test that uses the AntUnit lib
76 matches
Mail list logo
