2:30 p.m.
Having some problems getting the recently added byteman stuff to work in
terms of IntelliJ. Basically it comes down to I cannot find the byteman
jars anywhere. I run the compileTestJava task and see gradle/ivy
downloading the jars. But afterwards I cannot find them in
~/.gradle/cache. I also looked in ~/.m2/repository just to make sure,
but did not see them in there either. Thoughts?
--
steve(a)hibernate.org
http://hibernate.org
2:49 p.m.
Actually, not sure its really working in Gradle side either., I get
one failure after pull, which is the (afaict) single test using byteman:
Test org.hibernate.test.annotations.xml.ejb3.OrmVersion1SupportedTest
FAILED
java.lang.NoClassDefFoundError:
com/sun/tools/attach/AgentInitializationException
at
org.jboss.byteman.contrib.bmunit.BMUnitRunner$7.evaluate(BMUnitRunner.java:316)
So obviously byteman itself at least is being found when run from
Gradle, even though the test fails. But still cannot find where this
file went.
On Mon 19 Mar 2012 01:30:37 PM CDT, Steve Ebersole wrote:
Having some problems getting the recently added byteman stuff to work
in terms of IntelliJ. Basically it comes down to I cannot find the
byteman jars anywhere. I run the compileTestJava task and see
gradle/ivy downloading the jars. But afterwards I cannot find them in
~/.gradle/cache. I also looked in ~/.m2/repository just to make sure,
but did not see them in there either. Thoughts?
--
steve(a)hibernate.org
http://hibernate.org
2:56 p.m.
Ugh, I see... Gradle seems to now store repo caches by Gradle version
under ~/caches/{gradleVersion}. Anyway, the test still fails for me
locally...
On Mon 19 Mar 2012 01:49:04 PM CDT, Steve Ebersole wrote:
Actually, not sure its really working in Gradle side either., I get
one failure after pull, which is the (afaict) single test using byteman:
Test org.hibernate.test.annotations.xml.ejb3.OrmVersion1SupportedTest
FAILED
java.lang.NoClassDefFoundError:
com/sun/tools/attach/AgentInitializationException
at
org.jboss.byteman.contrib.bmunit.BMUnitRunner$7.evaluate(BMUnitRunner.java:316)
So obviously byteman itself at least is being found when run from
Gradle, even though the test fails. But still cannot find where this
file went.
On Mon 19 Mar 2012 01:30:37 PM CDT, Steve Ebersole wrote:
> Having some problems getting the recently added byteman stuff to work
> in terms of IntelliJ. Basically it comes down to I cannot find the
> byteman jars anywhere. I run the compileTestJava task and see
> gradle/ivy downloading the jars. But afterwards I cannot find them in
> ~/.gradle/cache. I also looked in ~/.m2/repository just to make sure,
> but did not see them in there either. Thoughts?
>
>
--
steve(a)hibernate.org
http://hibernate.org
3:10 p.m.
Hi Steve,
I guess who tested this was on OsX, and you are not.
Byteman requires the tools.jar from the JDK on it's classpath to be
able to load the agent dynamically (i.e. not require the agent to be
defined on the JVM boot parameters).
The tool.jar happens to be on the classpath by default when run on
Macs, but is not on Linux.
With Hibernate Search (Maven) we have it setup like:
https://github.com/hibernate/hibernate-search/blob/master/hibernate-searc...
Using a profile to detect where the jar is (end of the same file)
Sanne
On 19 March 2012 18:56, Steve Ebersole <steve(a)hibernate.org> wrote:
Ugh, I see... Gradle seems to now store repo caches by Gradle
version
under ~/caches/{gradleVersion}. Anyway, the test still fails for me
locally...
On Mon 19 Mar 2012 01:49:04 PM CDT, Steve Ebersole wrote:
> Actually, not sure its really working in Gradle side either., I get
> one failure after pull, which is the (afaict) single test using byteman:
>
> Test org.hibernate.test.annotations.xml.ejb3.OrmVersion1SupportedTest
> FAILED
>
> java.lang.NoClassDefFoundError:
> com/sun/tools/attach/AgentInitializationException
> at
> org.jboss.byteman.contrib.bmunit.BMUnitRunner$7.evaluate(BMUnitRunner.java:316)
>
>
> So obviously byteman itself at least is being found when run from
> Gradle, even though the test fails. But still cannot find where this
> file went.
>
> On Mon 19 Mar 2012 01:30:37 PM CDT, Steve Ebersole wrote:
>> Having some problems getting the recently added byteman stuff to work
>> in terms of IntelliJ. Basically it comes down to I cannot find the
>> byteman jars anywhere. I run the compileTestJava task and see
>> gradle/ivy downloading the jars. But afterwards I cannot find them in
>> ~/.gradle/cache. I also looked in ~/.m2/repository just to make sure,
>> but did not see them in there either. Thoughts?
>>
>>
>
--
steve(a)hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:53 p.m.
On Mar 19, 2012, at 8:10 PM, Sanne Grinovero wrote:
I guess who tested this was on OsX, and you are not.
I wonder who that could be :-) I was not aware of this side of using Byteman and
as Sanna says, it works just fine for me.
With Hibernate Search (Maven) we have it setup like:
https://github.com/hibernate/hibernate-search/blob/master/hibernate-searc...
Using a profile to detect where the jar is (end of the same file)
Hmm, that is a little more involved than I was hoping for. I still think that having
Byteman might be useful for
other tests as well (even though we would need a way to unify the two JUnit runners).
We have two options:
1. Drop the last commit I made for HHH-6271. This commit introduces byteman and could just
be removed
2. Work out how to do the profile equivalent in Gradle to make sure tools.jar is on the
classpath.
Thoughts?
--Hardy
1:15 a.m.
fixed
https://github.com/hibernate/hibernate-orm/commit/749f7c1eb5206ab456db08b...
and I'm seeing two test failures, probably caused by HHH-7020 / HHH-7090
:hibernate-core:testTest org.hibernate.test.connections.CurrentSessionConnectionTest
FAILED
Test org.hibernate.test.connections.AggressiveReleaseTest FAILED
481 tests completed, 2 failures
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
On Mar 20, 2012, at 4:53 AM, Hardy Ferentschik wrote:
On Mar 19, 2012, at 8:10 PM, Sanne Grinovero wrote:
> I guess who tested this was on OsX, and you are not.
I wonder who that could be :-) I was not aware of this side of using Byteman and
as Sanna says, it works just fine for me.
> With Hibernate Search (Maven) we have it setup like:
>
https://github.com/hibernate/hibernate-search/blob/master/hibernate-searc...
>
> Using a profile to detect where the jar is (end of the same file)
Hmm, that is a little more involved than I was hoping for. I still think that having
Byteman might be useful for
other tests as well (even though we would need a way to unify the two JUnit runners).
We have two options:
1. Drop the last commit I made for HHH-6271. This commit introduces byteman and could
just be removed
2. Work out how to do the profile equivalent in Gradle to make sure tools.jar is on the
classpath.
Thoughts?
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:18 a.m.
On Mar 20, 2012, at 1:15 PM, Strong Liu wrote:
FYI http://issues.gradle.org/browse/GRADLE-1477
and I'm seeing two test failures, probably caused by HHH-7020 / HHH-7090
:hibernate-core:testTest org.hibernate.test.connections.CurrentSessionConnectionTest
FAILED
Test org.hibernate.test.connections.AggressiveReleaseTest FAILED
481 tests completed, 2 failures
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
On Mar 20, 2012, at 4:53 AM, Hardy Ferentschik wrote:
>
> On Mar 19, 2012, at 8:10 PM, Sanne Grinovero wrote:
>
>> I guess who tested this was on OsX, and you are not.
>
> I wonder who that could be :-) I was not aware of this side of using Byteman and
> as Sanna says, it works just fine for me.
>
>> With Hibernate Search (Maven) we have it setup like:
>>
https://github.com/hibernate/hibernate-search/blob/master/hibernate-searc...
>>
>> Using a profile to detect where the jar is (end of the same file)
>
> Hmm, that is a little more involved than I was hoping for. I still think that having
Byteman might be useful for
> other tests as well (even though we would need a way to unify the two JUnit
runners).
>
> We have two options:
>
> 1. Drop the last commit I made for HHH-6271. This commit introduces byteman and could
just be removed
> 2. Work out how to do the profile equivalent in Gradle to make sure tools.jar is on
the classpath.
>
> Thoughts?
>
> --Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:33 a.m.
On Mar 20, 2012, at 6:15 AM, Strong Liu wrote:
Sweet :-) Cool that you figured it out.
--Hardy
4:32 a.m.
Nice, but I guess that won't work on Windows?
On 20 March 2012 06:33, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On Mar 20, 2012, at 6:15 AM, Strong Liu wrote:
> fixed
https://github.com/hibernate/hibernate-orm/commit/749f7c1eb5206ab456db08b...
Sweet :-) Cool that you figured it out.
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:42 a.m.
On Mar 20, 2012, at 4:32 PM, Sanne Grinovero wrote:
Nice, but I guess that won't work on Windows?
the file path separator?
On 20 March 2012 06:33, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
>
> On Mar 20, 2012, at 6:15 AM, Strong Liu wrote:
>
>> fixed
https://github.com/hibernate/hibernate-orm/commit/749f7c1eb5206ab456db08b...
>
> Sweet :-) Cool that you figured it out.
>
> --Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:02 a.m.
On 20 March 2012 08:42, Strong Liu <stliu(a)hibernate.org> wrote:
On Mar 20, 2012, at 4:32 PM, Sanne Grinovero wrote:
Nice, but I guess that won't work on Windows?
the file path separator?
Yes I'm thinking about the file separator, but I didn't try it.. maybe
it's fine because of some groovy magic.
For the same reason I'm surprised that the approach we use in Search
works, not sure why. Maybe windows has the same weirdness as OSX.
7:16 a.m.
On Mar 20, 2012, at 11:02, Sanne Grinovero <sanne(a)hibernate.org> wrote:
On 20 March 2012 08:42, Strong Liu <stliu(a)hibernate.org>
wrote:
>
> On Mar 20, 2012, at 4:32 PM, Sanne Grinovero wrote:
>
> Nice, but I guess that won't work on Windows?
>
>
> the file path separator?
Yes I'm thinking about the file separator, but I didn't try it.. maybe
it's fine because of some groovy magic.
For the same reason I'm surprised that the approach we use in Search
works, not sure why. Maybe windows has the same weirdness as OSX.
I think Maven as well as Groovy apply some magic when it comes to elements on
the classpath. Let's see what the ci jobs tell us.
--hardy
8:27 a.m.
Strong passed that to the Gradle file() method, which handles the file
separators I believe. files() does the same, calling file() for each
thing in whatever collection it is given.
I am curious Strong why you explicitly handle classes.jar (apparently
for MacOS) when it is already handled?
On 03/20/2012 06:16 AM, Hardy Ferentschik wrote:
On Mar 20, 2012, at 11:02, Sanne Grinovero<sanne(a)hibernate.org>
wrote:
> On 20 March 2012 08:42, Strong Liu<stliu(a)hibernate.org> wrote:
>> On Mar 20, 2012, at 4:32 PM, Sanne Grinovero wrote:
>>
>> Nice, but I guess that won't work on Windows?
>>
>>
>> the file path separator?
> Yes I'm thinking about the file separator, but I didn't try it.. maybe
> it's fine because of some groovy magic.
> For the same reason I'm surprised that the approach we use in Search
> works, not sure why. Maybe windows has the same weirdness as OSX.
I think Maven as well as Groovy apply some magic when it comes to elements on
the classpath. Let's see what the ci jobs tell us.
--hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
steve(a)hibernate.org
http://hibernate.org
5:31 a.m.
On Mar 20, 2012, at 1:27 PM, Steve Ebersole wrote:
I am curious Strong why you explicitly handle classes.jar (apparently
for MacOS) when it is already handled?
Right, I think we should get away w/ just
toolsJar =
file("${System.getProperty('java.home')}/../lib/tools.jar")
At least for Linux and Mac. I tried it and it works (for Mac)
That said, I am having the following problem:
Could not resolve all dependencies for configuration
':hibernate-infinispan:testCompile'.
Artifact
'org.infinispan:infinispan-core:5.1.2.FINAL:tests@jar' not found.
I already deleted .gradle and did a full rebuild, no success. I am going to delete
~.gradle as well now,
but otherwise I don't know what to do. Anyone else seeing this problem?
--Hardy
5:47 a.m.
On 22 March 2012 09:31, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On Mar 20, 2012, at 1:27 PM, Steve Ebersole wrote:
> I am curious Strong why you explicitly handle classes.jar (apparently
> for MacOS) when it is already handled?
Right, I think we should get away w/ just
toolsJar =
file("${System.getProperty('java.home')}/../lib/tools.jar")
At least for Linux and Mac. I tried it and it works (for Mac)
That said, I am having the following problem:
Could not resolve all dependencies for configuration
':hibernate-infinispan:testCompile'.
The jar seems to be correctly uploaded:
https://repository.jboss.org/nexus/content/groups/public-jboss/org/infini...
But I get your same error when running tests:
* What went wrong:
Could not resolve all dependencies for configuration
':hibernate-infinispan:testCompile'.
Artifact
'org.infinispan:infinispan-core:5.1.2.FINAL:tests@jar' not found.
I already deleted .gradle and did a full rebuild, no success. I am going to delete
~.gradle as well now,
but otherwise I don't know what to do. Anyone else seeing this problem? Artifact
'org.infinispan:infinispan-core:5.1.2.FINAL:tests@jar' not found.
This is what I see with --debug:
09:40:38.664 [DEBUG]
[org.gradle.api.internal.artifacts.repositories.ResourceCollectionResolver]
Loading
/home/sanne/.m2/repository/org/infinispan/infinispan-core/5.1.2.FINAL/infinispan-core-5.1.2.FINAL-tests.jar
09:40:38.665 [DEBUG]
[org.gradle.api.internal.artifacts.repositories.ResourceCollectionResolver]
Resource not reachable for org/infinispan#infinispan-core;5.1.2.FINAL:
res=/home/sanne/.m2/repository/org/infinispan/infinispan-core/5.1.2.FINAL/infinispan-core-5.1.2.FINAL-tests.jar
Indeed, that file is not there. The normal jar (not _test_) is there
already, in this case gradle is not attempting to download the
-tests.jar
Deleting the whole artifact directory:
/.m2/repository/org/infinispan/infinispan-core/5.1.2.FINAL/i
got gradle to download the tests artifact as well, and fixed the problem for me.
It looks like this problem is triggered if you build Core first
without running tests - which will download the Infinispan core jar -
but without running the tests: then it will fail if running tests
after that.
Cheers,
Sanne
--Hardy
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:08 a.m.
Hi,
The jar seems to be correctly uploaded:
https://repository.jboss.org/nexus/content/groups/public-jboss/org/infini...
But I get your same error when running tests:
* What went wrong:
Could not resolve all dependencies for configuration
':hibernate-infinispan:testCompile'.
> Artifact 'org.infinispan:infinispan-core:5.1.2.FINAL:tests@jar' not found.
This is what I see with --debug:
09:40:38.664 [DEBUG]
[org.gradle.api.internal.artifacts.repositories.ResourceCollectionResolver]
Loading
/home/sanne/.m2/repository/org/infinispan/infinispan-core/5.1.2.FINAL/infinispan-core-5.1.2.FINAL-tests.jar
09:40:38.665 [DEBUG]
[org.gradle.api.internal.artifacts.repositories.ResourceCollectionResolver]
Resource not reachable for org/infinispan#infinispan-core;5.1.2.FINAL:
res=/home/sanne/.m2/repository/org/infinispan/infinispan-core/5.1.2.FINAL/infinispan-core-5.1.2.FINAL-tests.jar
Indeed, that file is not there. The normal jar (not _test_) is there
already, in this case gradle is not attempting to download the
-tests.jar
Deleting the whole artifact directory:
/.m2/repository/org/infinispan/infinispan-core/5.1.2.FINAL/i
got gradle to download the tests artifact as well, and fixed the problem for me.
Same here. Deleting the 5.1.2.FINAL directory from the local repo and rebuilding fixed the
problem.
thanks,
Hardy
8:26 a.m.
You'll have to give me more info. All tests pass here for me aside from
the one originally discussed on this thread:
Building > :hibernate-core:matrixUnitTest > Resolving
dependencies
':hibernate:hibernate-core:matrixUnitTest
Test org.hibernate.test.annotations.xml.ejb3.OrmVersion1SupportedTest
FAILED
3030 tests completed, 1 failure
On 03/20/2012 12:15 AM, Strong Liu wrote:
fixed
https://github.com/hibernate/hibernate-orm/commit/749f7c1eb5206ab456db08b...
and I'm seeing two test failures, probably caused by HHH-7020 / HHH-7090
:hibernate-core:testTest org.hibernate.test.connections.CurrentSessionConnectionTest
FAILED
Test org.hibernate.test.connections.AggressiveReleaseTest FAILED
481 tests completed, 2 failures
-------------------------
Best Regards,
Strong Liu<stliu at hibernate.org>
http://about.me/stliu/bio
On Mar 20, 2012, at 4:53 AM, Hardy Ferentschik wrote:
> On Mar 19, 2012, at 8:10 PM, Sanne Grinovero wrote:
>
>> I guess who tested this was on OsX, and you are not.
> I wonder who that could be :-) I was not aware of this side of using Byteman and
> as Sanna says, it works just fine for me.
>
>> With Hibernate Search (Maven) we have it setup like:
>>
https://github.com/hibernate/hibernate-search/blob/master/hibernate-searc...
>>
>> Using a profile to detect where the jar is (end of the same file)
> Hmm, that is a little more involved than I was hoping for. I still think that having
Byteman might be useful for
> other tests as well (even though we would need a way to unify the two JUnit
runners).
>
> We have two options:
>
> 1. Drop the last commit I made for HHH-6271. This commit introduces byteman and could
just be removed
> 2. Work out how to do the profile equivalent in Gradle to make sure tools.jar is on
the classpath.
>
> Thoughts?
>
> --Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
steve(a)hibernate.org
http://hibernate.org
12:59 a.m.
FWIW, I'm not getting those 2 connection failures either, the only tests
that fail the majority of the time for me locally are the infinispan
ones (from the other test failure thread), although they sometimes pass
but mostly blow about 20 failures, which was also happening on a clean
pull of 4.1.1
-----Original Message-----
From: hibernate-dev-bounces(a)lists.jboss.org
[mailto:hibernate-dev-bounces@lists.jboss.org] On Behalf Of Steve
Ebersole
Sent: Tuesday, March 20, 2012 6:27 AM
To: hibernate-dev(a)lists.jboss.org
Subject: Re: [hibernate-dev] byteman
You'll have to give me more info. All tests pass here for me aside from
the one originally discussed on this thread:
Building > :hibernate-core:matrixUnitTest > Resolving
dependencies
':hibernate:hibernate-core:matrixUnitTest
Test org.hibernate.test.annotations.xml.ejb3.OrmVersion1SupportedTest
FAILED
3030 tests completed, 1 failure
On 03/20/2012 12:15 AM, Strong Liu wrote:
fixed
https://github.com/hibernate/hibernate-orm/commit/749f7c1eb5206ab456db
08bb901befa39ac5c11e
and I'm seeing two test failures, probably caused by HHH-7020 /
HHH-7090
:hibernate-core:testTest
org.hibernate.test.connections.CurrentSessionConnectionTest FAILED
Test org.hibernate.test.connections.AggressiveReleaseTest FAILED
481 tests completed, 2 failures
-------------------------
Best Regards,
Strong Liu<stliu at hibernate.org>
http://about.me/stliu/bio
On Mar 20, 2012, at 4:53 AM, Hardy Ferentschik wrote:
> On Mar 19, 2012, at 8:10 PM, Sanne Grinovero wrote:
>
>> I guess who tested this was on OsX, and you are not.
> I wonder who that could be :-) I was not aware of this side of using
> Byteman and as Sanna says, it works just fine for me.
>
>> With Hibernate Search (Maven) we have it setup like:
>> https://github.com/hibernate/hibernate-search/blob/master/hibernate-
>> search-orm/pom.xml#L157
>>
>> Using a profile to detect where the jar is (end of the same file)
> Hmm, that is a little more involved than I was hoping for. I still
> think that having Byteman might be useful for other tests as well
(even though
we would need a way to unify the two JUnit runners).
>
> We have two options:
>
> 1. Drop the last commit I made for HHH-6271. This commit introduces
> byteman and could just be removed 2. Work out how to do the profile
equivalent
in Gradle to make sure tools.jar is on the classpath.
>
> Thoughts?
>
> --Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
steve(a)hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4417
days inactive
4420
days old
17 comments
5 participants
participants (5)
-
Hardy Ferentschik -
Sanne Grinovero -
Shawn Clowater -
Steve Ebersole -
Strong Liu