Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #10124 > unrolled thread

Help needed: gradle + testng

Back to article view | Back to linux.debian.maint.java

Contents

  Help needed: gradle + testng olivier sallou <osallou@debian.org> - 2017-10-31 15:50 +0100
    Re: Help needed: gradle + testng Emmanuel Bourg <ebourg@apache.org> - 2017-10-31 16:50 +0100
      Re: Help needed: gradle + testng Olivier Sallou <olivier.sallou@irisa.fr> - 2017-10-31 17:00 +0100
    Re: Help needed: gradle + testng Markus Koschany <apo@debian.org> - 2017-10-31 17:00 +0100
      Re: Help needed: gradle + testng Olivier Sallou <olivier.sallou@irisa.fr> - 2017-10-31 17:20 +0100
        Re: Help needed: gradle + testng Olivier Sallou <olivier.sallou@irisa.fr> - 2017-10-31 17:40 +0100
          Re: Help needed: gradle + testng Olivier Sallou <olivier.sallou@irisa.fr> - 2017-10-31 17:50 +0100
            Re: Help needed: gradle + testng Markus Koschany <apo@debian.org> - 2017-10-31 17:50 +0100
              Re: Help needed: gradle + testng Olivier Sallou <olivier.sallou@irisa.fr> - 2017-10-31 18:00 +0100
                Re: Help needed: gradle + testng Markus Koschany <apo@debian.org> - 2017-11-19 16:50 +0100
                  Re: Help needed: gradle + testng Emmanuel Bourg <ebourg@apache.org> - 2017-11-20 11:40 +0100
                  Re: Help needed: gradle + testng Emmanuel Bourg <ebourg@apache.org> - 2017-11-20 23:40 +0100
                    Re: Help needed: gradle + testng Markus Koschany <apo@debian.org> - 2017-11-21 23:40 +0100
                      Re: Help needed: gradle + testng Markus Koschany <apo@gambaru.de> - 2017-11-26 21:30 +0100
                        Re: Help needed: gradle + testng Emmanuel Bourg <ebourg@apache.org> - 2017-11-28 00:50 +0100
                          Re: Help needed: gradle + testng Markus Koschany <apo@debian.org> - 2017-11-29 19:10 +0100
                            Re: Help needed: gradle + testng Emmanuel Bourg <ebourg@apache.org> - 2017-11-29 23:20 +0100
          Re: Help needed: gradle + testng Markus Koschany <apo@debian.org> - 2017-10-31 17:50 +0100

#10124 — Help needed: gradle + testng

[Multipart message — attachments visible in raw view] — view raw

Hi,

when using testng with gradle on some packages (get same issue on multiple
projects),

test step fails with error:


Executing task ':test' (up-to-date check took 0.0 secs) due to:

  Task.upToDateWhen is false.

Cannot nest operations in the same thread. Each nested operation must run
in its own thread.

java.lang.UnsupportedOperationException: Cannot nest operations in the same
thread. Each nested operation must run in its own thread.

at
org.gradle.internal.operations.DefaultBuildOperationWorkerRegistry.doStartOperation(DefaultBuildOperationWorkerRegistry.java:65)
....
and this message is repeat a large number of times (per test?)

any idea of what is wrong?

I tried with debian testng jar file and also tried to get a more recent one
(just in case), but same issue.

Thanks
Olivier

[toc] | [next] | [standalone]

#10125

Le 31/10/2017 à 15:40, olivier sallou a écrit :

> any idea of what is wrong?

I've seen this error too with another package and I had to disable the
tests. No idea what is causing this.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#10126

On 10/31/2017 04:43 PM, Emmanuel Bourg wrote:
> Le 31/10/2017 à 15:40, olivier sallou a écrit :
>
>> any idea of what is wrong?
> I've seen this error too with another package and I had to disable the
> tests. No idea what is causing this.
well, this is what I plan to do in a first step.

It occurs in several gradle+testng packages. Do not know if debian
gradle /  testng / helper issue  .
> Emmanuel Bourg
>

-- 


gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

[toc] | [prev] | [next] | [standalone]

#10127

[Multipart message — attachments visible in raw view] — view raw

Am 31.10.2017 um 15:40 schrieb olivier sallou:
[...]

> any idea of what is wrong?

Maybe it's a race condition. Have you tried building with --no-parallel
in case you use compat level 10? It might also be a bug in Gradle itself
according to some information on the web.

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#10128

[Multipart message — attachments visible in raw view] — view raw

On 10/31/2017 04:53 PM, Markus Koschany wrote:
> Am 31.10.2017 um 15:40 schrieb olivier sallou:
> [...]
>
>> any idea of what is wrong?
> Maybe it's a race condition. Have you tried building with --no-parallel
I tried debhelper directly, removing some arguements, to test manually,
but the same....

Tested:
gradle --debug --offline --stacktrace --no-daemon --refresh-dependencies
--gradle-user-home .gradle -Duser.home=. -Duser.name=debian
-Ddebian.package=picard-tools -Dfile.encoding=UTF-8  test

vs original:

gradle --info --console plain --offline --stacktrace --no-daemon
--refresh-dependencies --gradle-user-home .gradle -Duser.home=.
-Duser.name=debian -Ddebian.package=picard-tools -Dfile.encoding=UTF-8
--parallel --max-workers=4 test

same result.
> in case you use compat level 10? It might also be a bug in Gradle itself
> according to some information on the web.
>
> Regards,
>
> Markus
>

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

[toc] | [prev] | [next] | [standalone]

#10129

[Multipart message — attachments visible in raw view] — view raw

On 10/31/2017 05:15 PM, Olivier Sallou wrote:
>
> On 10/31/2017 04:53 PM, Markus Koschany wrote:
>> Am 31.10.2017 um 15:40 schrieb olivier sallou:
>> [...]
>>
>>> any idea of what is wrong?
>> Maybe it's a race condition. Have you tried building with --no-parallel
> I tried debhelper directly, removing some arguements, to test manually,
> but the same....
>
> Tested:
> gradle --debug --offline --stacktrace --no-daemon --refresh-dependencies
> --gradle-user-home .gradle -Duser.home=. -Duser.name=debian
> -Ddebian.package=picard-tools -Dfile.encoding=UTF-8  test
>
> vs original:
>
> gradle --info --console plain --offline --stacktrace --no-daemon
> --refresh-dependencies --gradle-user-home .gradle -Duser.home=.
> -Duser.name=debian -Ddebian.package=picard-tools -Dfile.encoding=UTF-8
> --parallel --max-workers=4 test
>
> same result.
 if I download gradle, and recompile/test using the new gradle, it works
fine (but keeping everything offline and copying
/usr/share/java|maven-repo related stuff manually to .m2 directory)

so either this is a debian gradle issue, either it is gradle helper issue.
>> in case you use compat level 10? It might also be a bug in Gradle itself
>> according to some information on the web.
>>
>> Regards,
>>
>> Markus
>>

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

[toc] | [prev] | [next] | [standalone]

#10130

[Multipart message — attachments visible in raw view] — view raw

On 10/31/2017 05:42 PM, Markus Koschany wrote:
> Am 31.10.2017 um 17:36 schrieb Olivier Sallou:
> [...]
>>  if I download gradle, and recompile/test using the new gradle, it works
>> fine (but keeping everything offline and copying
>> /usr/share/java|maven-repo related stuff manually to .m2 directory)
>>
>> so either this is a debian gradle issue, either it is gradle helper issue.
> I presume it is a Gradle bug then. I can try to update the package to
> version 3.4 which will allegedly resolve the issue.
the version I downloaded/tested with is gradle 4.3.
Do you want I try with a an older version ? (3.4.1, 3.5, ??)

Olivier

>
> Markus
>

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

[toc] | [prev] | [next] | [standalone]

#10132

[Multipart message — attachments visible in raw view] — view raw

I'm subscribed to debian-java. No need to CC me.

Am 31.10.2017 um 17:44 schrieb Olivier Sallou:
> the version I downloaded/tested with is gradle 4.3.
> Do you want I try with a an older version ? (3.4.1, 3.5, ??)

Updating Gradle can be a very painful experience. I assume updating to
4.3 will be complicated at best hence I'd prefer to take smaller steps.
You could try with 3.4 again. According to some upstream bug reports
either this version or even 3.3 should already work for you.

[toc] | [prev] | [next] | [standalone]

#10133

[Multipart message — attachments visible in raw view] — view raw

On 10/31/2017 05:47 PM, Markus Koschany wrote:
> I'm subscribed to debian-java. No need to CC me.
sorry, was a reply all instead of reply...
>
> Am 31.10.2017 um 17:44 schrieb Olivier Sallou:
>> the version I downloaded/tested with is gradle 4.3.
>> Do you want I try with a an older version ? (3.4.1, 3.5, ??)
> Updating Gradle can be a very painful experience. I assume updating to
> 4.3 will be complicated at best hence I'd prefer to take smaller steps.
> You could try with 3.4 again. According to some upstream bug reports
> either this version or even 3.3 should already work for you.
testing with 3.4 which launches the tests, no error.

What I did:

gbp buildpackage ....

after failure, go to build-area for package and execute manually the
command normally executed by debhelper:

gradle --debug --console plain  --stacktrace --no-daemon
--refresh-dependencies --gradle-user-home .gradle -Duser.home=.
-Dusere=debian -Ddebian.package=picard-tools -Dfile.encoding=UTF-8
--parallel --max-workers=4 test

=> failure as during gbp buildpackage

install gradle 3.4 and add to path

copy in .m2 dependencies from /usr/share/java/maven-repo
reexecute command using "new" gradle

gradle --debug --console plain  --stacktrace --no-daemon
--refresh-dependencies --gradle-user-home .gradle -Duser.home=.
-Dusere=debian -Ddebian.package=picard-tools -Dfile.encoding=UTF-8
--parallel --max-workers=4 test

=> success, tests are executed


so v3.4 should be ok
maybe going to 3.4.1 would be nicer (just some fixed issues on 3.4,
should be no different)

Olivier

>

-- 
Olivier Sallou
IRISA / University of Rennes 1
Campus de Beaulieu, 35000 RENNES - FRANCE
Tel: 02.99.84.71.95

gpg key id: 4096R/326D8438  (keyring.debian.org)
Key fingerprint = 5FB4 6F83 D3B9 5204 6335  D26D 78DC 68DB 326D 8438

[toc] | [prev] | [next] | [standalone]

#10153

[Multipart message — attachments visible in raw view] — view raw

Hi,

I have refreshed all patches for version 3.4.1 but I'm currently stuck
with a strange problem. The error message is:

Could not expand ZIP
'/home/apo/src/java/gradle/debian/.gradlehome/caches/3.2.1/generated-gradle-jars/gradle-api-3.2.1.jar'.


I have verified that the file exists and the permissions appear to be
correct. I can extract the jar file with unzip. Has anyone who worked
with gradle seen this error message before? Full build log with debug
mode can be found at [1].

[1] ftp://46.182.19.245/gradle.gz

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#10154

Le 19/11/2017 à 16:45, Markus Koschany a écrit :
> Hi,
> 
> I have refreshed all patches for version 3.4.1 but I'm currently stuck
> with a strange problem. The error message is:
> 
> Could not expand ZIP
> '/home/apo/src/java/gradle/debian/.gradlehome/caches/3.2.1/generated-gradle-jars/gradle-api-3.2.1.jar'.


The issue is related to ASM. We still use the 6.0~alpha version, I'll
update it to the latest version, that might help.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#10158

Markus, could you try again with groovy/2.4.8-3 please? I removed the
module-info.class files that could have caused the issue you
encountered. If it doesn't work I'll upload ASM 6.0 to experimental.

Emmanuel

[toc] | [prev] | [next] | [standalone]

#10161

[Multipart message — attachments visible in raw view] — view raw

Am 20.11.2017 um 23:34 schrieb Emmanuel Bourg:
> Markus, could you try again with groovy/2.4.8-3 please? I removed the
> module-info.class files that could have caused the issue you
> encountered. If it doesn't work I'll upload ASM 6.0 to experimental.
> 
> Emmanuel

Hi,

thanks for working on this issue. After the groovy update it seems to
work now.

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#10169

[Multipart message — attachments visible in raw view] — view raw

Hello,

Yesterday I have uploaded Gradle 3.4.1 to experimental. I have rebuilt
almost all reverse-dependencies of gradle/gradle-debian-helper by now
and so far it looks quite good with two notable regressions: mockito and bnd

bnd:
====

Error  : Unexpected ProjectBuilder init,  error
java.lang.IllegalArgumentException: A Jar can only accept a valid file
or directory: /build/bnd-2.4.1/biz.aQute.bnd.annotation/bin,

mockito
=======

Cannot locate JAR for module 'junit' in distribution directory
'/usr/share/gradle'.


I believe the bnd error is a compatibility issue and probably requires a
patch again.

Though mockito could also be a gradle packaging error hence I would
appreciate another look at this package before I'm going to upload
Gradle to unstable. I wonder why Gradle is only looking in
/usr/share/gradle (GRADLE_HOME) and not also in /usr/share/java. I
thought this patch [1] was responsible for searching in both
directories. In any case why is Gradle looking for a junit module?
Feedback is welcome.

Regards,

Markus

[1]
https://anonscm.debian.org/cgit/pkg-java/gradle.git/tree/debian/patches/search_system_jar.diff?h=experimental

[toc] | [prev] | [next] | [standalone]

#10176

On 11/26/2017 09:23 PM, Markus Koschany wrote:

> Yesterday I have uploaded Gradle 3.4.1 to experimental. I have rebuilt
> almost all reverse-dependencies of gradle/gradle-debian-helper by now
> and so far it looks quite good with two notable regressions: mockito and bnd

Well done! Thanks a lot for this update.


> bnd:
> ====
> 
> Error  : Unexpected ProjectBuilder init,  error
> java.lang.IllegalArgumentException: A Jar can only accept a valid file
> or directory: /build/bnd-2.4.1/biz.aQute.bnd.annotation/bin,

Does it also fail when building bnd directly with gradle, without
debuild/dpkg-buildpackage? I suggest also trying with the latest bnd
release fetched from the upstream repository. If the issue was solved
upstream we could update bnd before uploading gradle to unstable (or
backport the fix).


> mockito
> =======
> 
> Cannot locate JAR for module 'junit' in distribution directory
> '/usr/share/gradle'.

Maybe it's looking for junit.jar and /usr/share/java only contains
junit4.jar?

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#10192

[Multipart message — attachments visible in raw view] — view raw

Am 28.11.2017 um 00:07 schrieb Emmanuel Bourg:
> On 11/26/2017 09:23 PM, Markus Koschany wrote:
> 
>> Yesterday I have uploaded Gradle 3.4.1 to experimental. I have rebuilt
>> almost all reverse-dependencies of gradle/gradle-debian-helper by now
>> and so far it looks quite good with two notable regressions: mockito and bnd
> 
> Well done! Thanks a lot for this update.
> 
> 
>> bnd:
>> ====
>>
>> Error  : Unexpected ProjectBuilder init,  error
>> java.lang.IllegalArgumentException: A Jar can only accept a valid file
>> or directory: /build/bnd-2.4.1/biz.aQute.bnd.annotation/bin,
> 
> Does it also fail when building bnd directly with gradle, without
> debuild/dpkg-buildpackage? I suggest also trying with the latest bnd
> release fetched from the upstream repository. If the issue was solved
> upstream we could update bnd before uploading gradle to unstable (or
> backport the fix).

It doesn't build for me with pure gradle either. The latest version
works when I skip the tests but I don't know how comparable that is
because the upstream version comes with tons of prebuilt jar files and
happily downloads even more from the internet. One update of bnd per
release cycle would definitely be nice but I flinch from doing it at the
moment because I can still recall the 30+ reverse-dependency updates
when I did the 1.5 -> 2.1 transition and there are other tasks which I
want to do first.


>> mockito
>> =======
>>
>> Cannot locate JAR for module 'junit' in distribution directory
>> '/usr/share/gradle'.
> 
> Maybe it's looking for junit.jar and /usr/share/java only contains
> junit4.jar?

I have fixed this issue by updating gradle's use-local-artifacts.patch.
Instead of looking for the junit module it now checks for junit4. I'm
not sure why this was working with the previous version though. I also
had to add testng as a new build-dependency for mockito and changing the
maven rules was also required but now it works. This problem appears to
be solved.

> Emmanuel Bourg

Regards,

Markus

[toc] | [prev] | [next] | [standalone]

#10193

Le 29/11/2017 à 19:08, Markus Koschany a écrit :

> It doesn't build for me with pure gradle either. The latest version
> works when I skip the tests but I don't know how comparable that is
> because the upstream version comes with tons of prebuilt jar files and
> happily downloads even more from the internet. One update of bnd per
> release cycle would definitely be nice but I flinch from doing it at the
> moment because I can still recall the 30+ reverse-dependency updates
> when I did the 1.5 -> 2.1 transition and there are other tasks which I
> want to do first.

Fair enough ;) I'll give it a try.


> I have fixed this issue by updating gradle's use-local-artifacts.patch.
> Instead of looking for the junit module it now checks for junit4. I'm
> not sure why this was working with the previous version though.

I guess junit was pulled via some of the Maven dependencies (most
certainly plexus-container-default) and it went away with the completion
of the Maven 3 transition.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#10131

[Multipart message — attachments visible in raw view] — view raw

Am 31.10.2017 um 17:36 schrieb Olivier Sallou:
[...]
>  if I download gradle, and recompile/test using the new gradle, it works
> fine (but keeping everything offline and copying
> /usr/share/java|maven-repo related stuff manually to .m2 directory)
> 
> so either this is a debian gradle issue, either it is gradle helper issue.

I presume it is a Gradle bug then. I can try to update the package to
version 3.4 which will allegedly resolve the issue.

Markus

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.java

csiph-web