On 2018-05-20, Gintautas Grigelionis wrote:
> 2018-05-20 19:52 GMT+02:00 Stefan Bodewig :
>>> Hi all
>>> while running all tests locally I saw dependeset-test is failing, they
>>> are also failing on Jenkins.
>> Found it
>> https://github.com/apache/ant/commit/11422630936848e82c7b13a
>> b3fa68
2018-05-20 19:52 GMT+02:00 Stefan Bodewig :
> > Hi all
>
> > while running all tests locally I saw dependeset-test is failing, they
> > are also failing on Jenkins.
>
> Found it
>
> https://github.com/apache/ant/commit/11422630936848e82c7b13a
> b3fa68a3003e10195#diff-d84918760549fe4c0e195ba6cbfef4
On 2018-05-20, Stefan Bodewig wrote:
> Hi all
> while running all tests locally I saw dependeset-test is failing, they
> are also failing on Jenkins. The last known good revision is
> 0020d1a16ba4207289d2380dc6981c85455b617f
> Is anybody already looking into this?
Found it
https://github.com/a
Hi all
while running all tests locally I saw dependeset-test is failing, they
are also failing on Jenkins. The last known good revision is
0020d1a16ba4207289d2380dc6981c85455b617f
Is anybody already looking into this?
Stefan
-
On 2018-03-20, Stefan Bodewig wrote:
> it looks as if I had broken every single Jenkins build. Of course the
> test pass on my machine with all JDKs I've got installed.
No, it fails on Java10 for me, because jarsigner -verify now dies for a
self-signed certificate. I'll try to figure out when thi
Hi all
it looks as if I had broken every single Jenkins build. Of course the
test pass on my machine with all JDKs I've got installed.
Can anybody who gets test errors in his/her local environment please run
./build.sh -f src/tests/antunit/taskdefs/signjar-test.xml
testVerifyJarStrictPKCS12 -v
On 2018-03-01, Gintautas Grigelionis wrote:
> Build File: .../src/tests/antunit/taskdefs/copy-test.xml
> Tests run: 26, Failures: 0, Errors: 2, Time elapsed: 8,59 sec
Passes for me locally as well as on Jenkins
https://builds.apache.org/view/A-D/view/Ant/job/Ant-Build-Matrix-master-Linux/OS=xeni
I just tried locally both with Java 8 and 9:
java version "9.0.1"
Java(TM) SE Runtime Environment (build 9.0.1+11)
Java HotSpot(TM) 64-Bit Server VM (build 9.0.1+11, mixed mode)
They pass for me:
[au:antunit] Tests run: 26, Failures: 0, Errors: 0, Time elapsed: 9.175 sec
[au:antunit] Target: t
I see following in my builds against master
Build File: .../src/tests/antunit/taskdefs/copy-test.xml
Tests run: 26, Failures: 0, Errors: 2, Time elapsed: 8,59 sec
...
Target: test-with-some-resources-mapped-away caused an ERROR
at line 471, column 29
Message: Can't copy a resource without
On 2018-01-29, Jan Matèrne (jhm) wrote:
>> Well, the task wil not work with any future Java releases since the
>> internal APIs are not comming back.
>> Meanwhile, a quick search shows that while there is quite a lot
>> activity with image io, there is no equivalent of JAI.create() for
>> image t
> Well, the task wil not work with any future Java releases since the
> internal APIs are not comming back.
>
> Meanwhile, a quick search shows that while there is quite a lot
> activity with image io, there is no equivalent of JAI.create() for
> image transformations (on which the image task is b
Well, the task wil not work with any future Java releases since the
internal APIs are not comming back.
Meanwhile, a quick search shows that while there is quite a lot activity
with image io, there is no equivalent of JAI.create() for image
transformations
(on which the image task is based). Maybe
On 2018-01-29, Gintautas Grigelionis wrote:
> So, what can we do about com.sun.image.codec.jpeg that is finally gone in
> Java 9?
> BTW, I looked into the package dependencies in Java 8, and
> com.sun.image.codec.jpeg needs sun.awt.image.codec which in turn has JNI to
> native libraries.
> The pos
So, what can we do about com.sun.image.codec.jpeg that is finally gone in
Java 9?
BTW, I looked into the package dependencies in Java 8, and
com.sun.image.codec.jpeg needs sun.awt.image.codec which in turn has JNI to
native libraries.
The possible alternatives seem to be using ImageIO/Java 2D or dr
Sorry about the confusion, JBoss repository provides platform independent
versions.
Gintas
2018-01-24 7:29 GMT+01:00 Gintautas Grigelionis :
> When I updated the installation manual, I found the "official" JAI
> installation instruction [1].
> It mentions a platform-specific library, MediaLib [2
When I updated the installation manual, I found the "official" JAI
installation instruction [1].
It mentions a platform-specific library, MediaLib [2], provided only for
Win32, Linux (i586 and amd64) and Solaris.
Gintas
1. https://download.java.net/media/jai/builds/release/1_1_3/INSTALL.html
2. h
A brief look suggests that there's some underlying exception originating
from JAI library. For some reason, this test isn't included in the tests
that get run as part of our regular Jenkins builds. I'm not sure if
that's intentional, but I haven't looked at the build file in detail to
be sure.
On 2018-01-21, Gintautas Grigelionis wrote:
> I see three failures in ImageTest
> testSimpleScale (did not create largeimage.jpg)
> testSimpleScaleWithMapper (did not create largeimage-scaled.jpg)
> testOverwriteTrue (negative time)
> Could somebody confirm this, please?
They happen for me loca
I see three failures in ImageTest
testSimpleScale (did not create largeimage.jpg)
testSimpleScaleWithMapper (did not create largeimage-scaled.jpg)
testOverwriteTrue (negative time)
Could somebody confirm this, please?
Gintas
Github user nlalevee commented on the issue:
https://github.com/apache/ant-ivy/pull/30
I don't find the fix fully satisfying because it doesn't address the
fragile static set of circularDependencyId, it might produce some side effect
errors in the future. At least we should keep it mi
Github user asfgit closed the pull request at:
https://github.com/apache/ant-ivy/pull/30
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enab
Github user jaikiran commented on the issue:
https://github.com/apache/ant-ivy/pull/30
Jenkins seems to have picked up the disabled Matrix job for this run. I'll
wait for that to get sorted out.
---
If your project is set up for it, you can reply to this email and have your
reply app
GitHub user jaikiran opened a pull request:
https://github.com/apache/ant-ivy/pull/30
Fix transient test failures
The commit here fixes the transient test failures that we keep seeing in
`WarnCircularDependencyStrategyTest`. More details about the fix are in this
previous PR https
Github user jaikiran commented on the issue:
https://github.com/apache/ant-ivy/pull/22
That's a good find. Looking at that testcase now again, with this
additional detail that you noted, I think the problem here is that the
`AbstractLogCircularDependencyStrategy` ends up using a `IvyC
Github user nlalevee commented on the issue:
https://github.com/apache/ant-ivy/pull/22
after many runs on my machine, I think I have found the actual issue. If
testRemoveDuplicates is run after testRemoveDuplicates2, then it fails. It
seems due to the fact that WarnCircularDependencyS
Github user jaikiran commented on the issue:
https://github.com/apache/ant-ivy/pull/22
Looks like this didn't help. It failed again (passes locally):
>> [junit] Running
org.apache.ivy.plugins.circular.WarnCircularDependencyStrategyTest
[junit] Tests run: 3, Failures: 1
Github user jaikiran closed the pull request at:
https://github.com/apache/ant-ivy/pull/22
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is en
GitHub user jaikiran opened a pull request:
https://github.com/apache/ant-ivy/pull/22
Fix transient test failures
The `WarnCircularDependencyStrategyTest` fails once in a while on Jenkins.
Looking at the testcase, it resets/updates a shared JVM level logger instance
(via
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
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 tomorrow
* some stange host-name resolution issue with the Ubun
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
I get a bunch of test failures in trunk using
$ ant -lib lib/optional/ant-antunit-1.2.jar antunit-tests
under JDK 7u3, Ubuntu. Are these tests normally expected to pass?
-
To unsubscribe, e-mail: dev-unsubscr
Hi all,
macrodef'ed tasks used to run their attributes through property
expansion twice (or even more often if the nested tasks of a macro have
been macros themselves).
https://issues.apache.org/bugzilla/show_bug.cgi?id=42046
The reason is they get expanded once for the macro instance and once
a
On 2011-03-02, Antoine Levy-Lambert wrote:
> On top of that I tried to make sense of the error message of
> replacetokens-test.xml (below) but I do not get it ...
> Regards,
> Antoine
> au:antunit] Build File:
> /srv/gump/public/workspace/ant/src/tests/antunit/filters/replacetokens-test.xml
>
Hi,
I just worked on import-url-test.xml and junit-outputtoformatters-test.xml.
I see some other tests which neeed fixing :
- replacetokens-test.xml
- native2ascii-test.xml
- rmic-test.xml
Seen the current time, I am not going to fix them tonight.
On top of that I tried to make sense of the er
On 3/1/2011 3:49 AM, Stefan Bodewig wrote:
On 2011-03-01, Antoine Levy-Lambert wrote:
OK I have done "something".
Thank you. I have tweaked a few things and am just running the full
testsuite on my windows box where problems with undeleteable jars tend
to show up.
Thanks too.
I have seen t
On 2011-03-01, Antoine Levy-Lambert wrote:
> OK I have done "something".
Thank you. I have tweaked a few things and am just running the full
testsuite on my windows box where problems with undeleteable jars tend
to show up.
> I have seen that the java resources like ${java:foo!foo.properties} i
OK I have done "something".
for taskdef-test.xml I have added 5 properties test1.jar to test5.jar
which correspond to work entries in gump.
I have seen that the java resources like ${java:foo!foo.properties} in
replacetokens-test.xml do not lend themselves to standardisation.
I wanted to replace
On 2/28/11 11:02 AM, Stefan Bodewig wrote:
> On 2011-02-28, Antoine Levy-Lambert wrote:
>
>> I see now that in fact there are still 21 antunit tests failing in gump
>> (see [1] and [2] below) :
>> Do we want to add a work entry in gump metadata for each of the
>> directories where these tests creat
On 2011-02-28, Antoine Levy-Lambert wrote:
> I see now that in fact there are still 21 antunit tests failing in gump
> (see [1] and [2] below) :
> Do we want to add a work entry in gump metadata for each of the
> directories where these tests create classes or resources ?
> Or do we want to someh
Hello Stefan,
I see now that in fact there are still 21 antunit tests failing in gump
(see [1] and [2] below) :
Do we want to add a work entry in gump metadata for each of the
directories where these tests create classes or resources ?
Or do we want to somehow standardize and have a convention th
On 12/7/2010 3:18 PM, Rod MacKenzie wrote:
ys 1.6).
Are you using Mac OS X 10.6? If so it only supports Java 1.6 by
default but has links/aliases for versions 1.3 to 1.5 that will run
Java 1.6. That may explain the Java version confusion.
Yes, I am using Mac OS X 10.6.
Rod
Thanks,
Antoine
On 7 December 2010 18:34, Antoine Levy-Lambert wrote:
> Hi,
>
> I just built trunk and ran the tests on Mac OS.
>
> I am not 100% sure whether I have been using Java 1.5 or 1.6 as my
> JAVA_HOME setting and java -version seem to be telling different stories
> ( my JAVA_HOME has a 1.5.0 in the path
Hi,
I just built trunk and ran the tests on Mac OS.
I am not 100% sure whether I have been using Java 1.5 or 1.6 as my
JAVA_HOME setting and java -version seem to be telling different stories
( my JAVA_HOME has a 1.5.0 in the path, but $JAVA_HOME/bin/java -version
says 1.6).
Anyway ExecuteJavaTe
creating the trouble.
Regards,
Antoine
Original-Nachricht
> Datum: Tue, 27 Oct 2009 17:59:46 +0100
> Von: Stefan Bodewig
> An: dev@ant.apache.org
> Betreff: Recurring Test Failures WRT Redirector
> Hi,
>
> almost every time I run the testsuite at least one of
On 2009-10-28, Kevin Jackson wrote:
> Hi,
>> almost every time I run the testsuite at least one of testRedirector13
>> or testRedirector14 in either ExecTaskTest.java or apply-test.xml fails
>> - but it doesn't happen all the time and you can't really predict which
>> one (or how many) of the fo
Hi,
> almost every time I run the testsuite at least one of testRedirector13
> or testRedirector14 in either ExecTaskTest.java or apply-test.xml fails
> - but it doesn't happen all the time and you can't really predict which
> one (or how many) of the four of them may fail or not.
>
> Smells like
Hi,
almost every time I run the testsuite at least one of testRedirector13
or testRedirector14 in either ExecTaskTest.java or apply-test.xml fails
- but it doesn't happen all the time and you can't really predict which
one (or how many) of the four of them may fail or not.
Smells like a race cond
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
--- 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.
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.g.
org.apache.tools.ant.util.regexp.JakartaOroMatcher .
I tested last fridays head against cygwin last night on my
win machine.
I saw the JarTest and the JDepend failures but not the
AntLikeTasksAtTopLevelTest failure.
I looked into the JDepend error - it also happens in raw windows mode.
The problem
is strange - the encoding of the string got from
On Mon, 1 Dec 2003, Antoine Lévy-Lambert <[EMAIL PROTECTED]> wrote:
> Hopefully the failures are more due to cygwin or to
> misconfigurations rather than anything else.
Can you run them under "plain Windows" using ant.bat and all that?
I don't get any failures running the tests on Linux.
Stefan
On my computer I get another failure:
Testcase: testAntlibResource(org.apache.tools.ant.taskdefs.AntlibTest):
Caused an ERROR
Could not create task or type of type: mytask2.
- Alexey.
Antoine Lévy-Lambert wrote:
While working on an improvement for regular expressions, I run the ant
testcases agai
While working on an improvement for regular expressions, I run the ant
testcases against ant head on Win2000/cygwin.
The results :
[junit] Testcase:
testAnt(org.apache.tools.ant.taskdefs.AntLikeTasksAtTopLevelTest): FAILED
[junit] Testcase:
testSubant(org.apache.tools.ant.taskdefs.Ant
On Tue, 2003-07-08 at 13:19, Stefan Bodewig wrote:
> On 08 Jul 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > On Mon, 2003-07-07 at 09:37, Stefan Bodewig wrote:
>
> >> So if we agreed that it is OK to add/remove tasks to the target
> >> currently being executed, we simply needed to provide a be
On 08 Jul 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> On Mon, 2003-07-07 at 09:37, Stefan Bodewig wrote:
>> So if we agreed that it is OK to add/remove tasks to the target
>> currently being executed, we simply needed to provide a better
>> implemenntation than the old one. 8-)
> It would be
On Tue, 8 Jul 2003 06:00 pm, peter reilly wrote:
>
> It would be difficult to provide a different implementation.
>
Wouldn't cloning the list before iteration do that. It would make the changes
ineffective but not terminal. Not sure if it worth the effort to prevent this
scenario.
> A thing to
On Mon, 2003-07-07 at 09:37, Stefan Bodewig wrote:
> On 07 Jul 2003, peter reilly <[EMAIL PROTECTED]> wrote:
>
> > I am not sure that that depending on an undocumented (I think)
> > feature of Vector/Enumeration is a good idea.
>
> I agree, though it is sort-of documented in Vector's javadocs (th
On 07 Jul 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> I am not sure that that depending on an undocumented (I think)
> feature of Vector/Enumeration is a good idea.
I agree, though it is sort-of documented in Vector's javadocs (the
class description).
,
| The Iterators returned by Vecto
I think in general it is not a good idea.
The code in question is:
in Target#execute
Iterator it = children.iterator();
Object o = it.next();
if (o instanceof Task) {
Task task = (Task) o;
task.perform();
On 04 Jul 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> The test code in question was inserting tasks
> into the current target, and this does not
> seem to be a good idea.
In general or just after the code change?
If we agree that adding tasks to the current target is no good idea in
general
I think this is due to a change of using
an iterator instead of a enumerator.
The test code in question was inserting tasks
into the current target, and this does not
seem to be a good idea.
I moved the place where the task is being placed
to another target and the test passes.
Peter
Conor wrote
I'm currently getting a failure in
org.apache.tools.ant.taskdefs.optional.RhinoScriptTest
It is a concurrent modification
[junit] java.util.ConcurrentModificationException
[junit] at
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:444)
[junit] at java.util
- Original Message -
From: "Steve Loughran" <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, June 25, 2003 2:30 AM
Subject: linux test failures
running on redhat 9.0, [SMP] and I'm seeing a regexp failure on Sun's
SDK:
They
ild(Main.java:618)
at org.apache.tools.ant.Main.start(Main.java:201)
at org.apache.tools.ant.Main.main(Main.java:248)
TEST org.apache.tools.ant.util.regexp.Jdk14RegexpRegexpTest FAILED
- Original Message -
From: "Steve Loughran" <[EMAIL PROTECTED]>
To: "Ant D
On 24 Jun 2003, Steve Loughran <[EMAIL PROTECTED]> wrote:
> running on redhat 9.0, [SMP] and I'm seeing a regexp failure on
> Sun's SDK:
Passes for me (same JDK but an older RedHat distro). I get
failures right now that I need to investigate.
Stefan
---
Hi Steve,
do you have a HEAD copy of Jdk14RegexpRegexp. I made
a bug fix to that recently - I put in the dollar test
to test it. (bug report 20306).
Peter.
On Wed, 2003-06-25 at 01:30, Steve Loughran wrote:
> running on redhat 9.0, [SMP] and I'm seeing a regexp failure on Sun's
> SDK:
>
>
> Tes
running on redhat 9.0, [SMP] and I'm seeing a regexp failure on Sun's
SDK:
Testcase:
testHandleDollerMatch(org.apache.tools.ant.filters.TokenFilterTest): C
aused an ERROR
Illegal group reference
java.lang.IllegalArgumentException: Illegal group reference
at java.util.regex.Matcher.appendR
[junit] Testcase:
testAttributes(org.apache.tools.ant.types.ZipFileSetTest):Caused an
ERROR
[junit] null
[junit] java.lang.NullPointerException
[junit] at
org.apache.tools.ant.types.ZipFileSetTest.testAttributes(ZipFileSetTest.java:149)
[junit] at java.lang.re
Hi,
Your guess is nearly right, I originally used beanshell,
after modifying it to use apache BSF. When submitting
I modified the tests to use javascript, but missed the
test to check if script is available.
Cheers,
Peter
On Tuesday 15 April 2003 07:39, Stefan Bodewig wrote:
> In addition, test
Ok, waiting for ending "solution 4" and decide later about the first three
:-)
Jan
> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Gesendet am: Dienstag, 15. April 2003 11:21
> An: [EMAIL PROTECTED]
> Betreff: Re: Test failures (
On Tue, 15 Apr 2003, Jan Materne <[EMAIL PROTECTED]> wrote:
> But I think this is a common problem.
Yes and no. Part of it is a manifestation of bug 18476, but that
wouldn't explain why a non-linefeed, non-cariage-return character gets
removed on Unix.
> 1. provide an input file --> platform de
alsIgnoreLineEndings()).
comment?
Jan Matèrne
> -Ursprüngliche Nachricht-
> Von: Stefan Bodewig [mailto:[EMAIL PROTECTED]
> Gesendet am: Dienstag, 15. April 2003 08:39
> An: [EMAIL PROTECTED]
> Betreff: Test failures (Gump is coming to tell us anyway ...)
>
> Like for Jesse, te
Like for Jesse, testTailSkip and testTailLinesSkip fail on Linux for
me, I bet it is a line ending problem. As the nightly Gump build is
performed on Linux as well, we are going to get nagged.
In addition, testScriptFilter fails. It seems as if the new filter
was using the old IBM BSF package na
82 matches
Mail list logo
