You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Gregory Shimansky <gs...@gmail.com> on 2006/11/02 20:31:00 UTC
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit
checks
Geir Magnusson Jr. wrote:
>
>
> Gregory Shimansky wrote:
>> Geir
>>
>> I actually was serious. Probably you were confused, I didn't write
>> "build test", I wrote "build smoke.test". The first one works ok, the
>> second doesn't.
>>
>> It happens because "test" (top-level test target) is handled in a
>> different way from "smoke.test" (target just for smoke test category)
>> target in build.xml. The "smoke.test" target just switches default
>> processing target to "smoke.test" and runs "process_components" (which
>> in its turn loops over all components). The "test" special handling of
>> processing components escapes me, I don't quite understand how it
>> works, but it seems to work correctly, without looping.
>
> I've used them both, and targetted smoke for specific use cases (opt, etc)
Hmm you probably know more about VM build than I do since you've been
modifying it for quite some time already. I've just started to look into
the whole thing.
>>
>> The question I was trying to solve was, how to correctly add
>> jvmti.test target to the build.xml so that it would run only jvmti
>> tests but not loop over components, but when "test" target it called,
>> jvmti tests category would be executed along with all other categories.
>>
>> Including "jvmti.test" target into build.xml in the same way as
>> "smoke.test" doesn't make me happy.
>
> Right - I thought you'd start a revolt and do it outside of the "loop
> over test types" system we have now.
Well I am not an ant guru, and the current build system definitely
requires some time to understand. I've tried to copy most of the stuff
from other test ant files to make my own. I think I'll file a JIRA
before committing it to make it possible to discuss it.
> In order to keep this simple, why not just have a separate test target
> for now
>
> $ sh build.sh test.jvmti
>
> and we can stare at that together, and figure out how to integrate...
> simplest thing would be to rename the current "test" target to
> "test_loop" or something, and then
>
> <target name="test" depends="test_loop, test.jvmti" />
>
> :)
Hmm good idea, why didn't I think of it myself?... :)
--
Gregory
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit
checks
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> Geir Magnusson Jr. wrote:
> > Gregory Shimansky wrote:
>>> One reason would be is that I don't know ant well enough to redesign
>>> the whole stuff all together. I used the existing setup and init
>>> targets which take care of including ancontrip and cctask jars.
>>>
>>> If you ask me, I'd prefer make in the first place, ant is just too
>>> foreign to me. There is no reason to use caps, we didn't even start
>>> to discuss how we want to see drlvm build and "when WE ARE GOING TO
>>> GET RID OF IT at some point".
>>
>> The caps were to get your attention. I thought you had a nice way to
>> create a standalone testbed and then hook that in.
>
> Well as I've written already, there is very much that is done in setup
> and init targets of drlvm build. It is checking for necessary jar files
> like junit, ant-contrib, cctask. Also these targets setup a lot of
> necessary properties. I just didn't want to duplicate all of that stuff.
>
> The fact that these targets (setup and init) also do XML transform is
> almost not used in jvmti tests. Yes there are 2 <select> which are
> processed in XML transform, but I can remove them when necessary. I
> consider this dependency on current drlvm build minor. If we decide to
> get rid of XML processing, the changes in jvmti tests build shall be
> minimal. Does it sound ok to you?
Hey, the work is done :)
The fact is, you can still have a dependency in init and setup to get
the goodness from there.
I hope to look at this on the plane home tonight.
>
>>> The time invested, well... I learned a lot since the last time I used
>>> ant. Maybe one day I'll be able to write something as impressive and
>>> unmaintainable as the current drlvm built :)
>>>
>>> Seriously, if we're going to change it, let's discuss it how we want
>>> it to look like and which tool we'll use. I vote for make (gnu
>>> version, that is gmake), even on win32 it exists in cygwin and mingw.
>>>
>>
>> I think that we should simply use the same tooling that we're using
>> now in classlib.
>
> Ok let's decide that exactly we don't like in the current drlvm build.
> Probably I should start another thread.
We decided that last may, didn't we?
geir
>
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit
checks
Posted by Gregory Shimansky <gs...@gmail.com>.
Geir Magnusson Jr. wrote:
> Gregory Shimansky wrote:
>> One reason would be is that I don't know ant well enough to redesign
>> the whole stuff all together. I used the existing setup and init
>> targets which take care of including ancontrip and cctask jars.
>>
>> If you ask me, I'd prefer make in the first place, ant is just too
>> foreign to me. There is no reason to use caps, we didn't even start to
>> discuss how we want to see drlvm build and "when WE ARE GOING TO GET
>> RID OF IT at some point".
>
> The caps were to get your attention. I thought you had a nice way to
> create a standalone testbed and then hook that in.
Well as I've written already, there is very much that is done in setup
and init targets of drlvm build. It is checking for necessary jar files
like junit, ant-contrib, cctask. Also these targets setup a lot of
necessary properties. I just didn't want to duplicate all of that stuff.
The fact that these targets (setup and init) also do XML transform is
almost not used in jvmti tests. Yes there are 2 <select> which are
processed in XML transform, but I can remove them when necessary. I
consider this dependency on current drlvm build minor. If we decide to
get rid of XML processing, the changes in jvmti tests build shall be
minimal. Does it sound ok to you?
>> The time invested, well... I learned a lot since the last time I used
>> ant. Maybe one day I'll be able to write something as impressive and
>> unmaintainable as the current drlvm built :)
>>
>> Seriously, if we're going to change it, let's discuss it how we want
>> it to look like and which tool we'll use. I vote for make (gnu
>> version, that is gmake), even on win32 it exists in cygwin and mingw.
>>
>
> I think that we should simply use the same tooling that we're using now
> in classlib.
Ok let's decide that exactly we don't like in the current drlvm build.
Probably I should start another thread.
--
Gregory
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit
checks
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> On Sunday 12 November 2006 00:39 Geir Magnusson Jr. wrote:
>>> Ok I think I've come up with a reasonable compromise. I still used the
>>> whole system of converting XML and all the stuff. It does quite a lot of
>>> things in setup and init targets and using <select> is convenient. I
>>> don't know how to untangle all of the setup and not do a lot of
>>> duplication in ant scripting which I am not big expert in.
>> Why? Why do we want to persist with this system, when WE ARE GOING TO
>> GET RID OF IT at some point?
>
> One reason would be is that I don't know ant well enough to redesign the whole
> stuff all together. I used the existing setup and init targets which take
> care of including ancontrip and cctask jars.
>
> If you ask me, I'd prefer make in the first place, ant is just too foreign to
> me. There is no reason to use caps, we didn't even start to discuss how we
> want to see drlvm build and "when WE ARE GOING TO GET RID OF IT at some
> point".
The caps were to get your attention. I thought you had a nice way to
create a standalone testbed and then hook that in.
>
>> Did you also fix the silliness of having to use annotations to exclude
>> tests? Please? :)
>
> No, the patch has an exclude example using and <exclude> statement in
> patternset in its beginning.
Yay!
>
>> I'm glad we have these tests, but really... I wish you hadn't invested
>> the time integrating it into the DRLVM build system...
>
> Even if we write a new one from scratch I want the tests right now. There were
> several times when JVMTI was broken since there were no tests for it at all
> since it is a special VM mode no one usually uses.
That's not the issue - we all agree we need the tests right now. What
I'm arguing about is doing the tests, and then doing the integration
into a build system we don't want.
>
> The time invested, well... I learned a lot since the last time I used ant.
> Maybe one day I'll be able to write something as impressive and
> unmaintainable as the current drlvm built :)
>
> Seriously, if we're going to change it, let's discuss it how we want it to
> look like and which tool we'll use. I vote for make (gnu version, that is
> gmake), even on win32 it exists in cygwin and mingw.
>
I think that we should simply use the same tooling that we're using now
in classlib.
geir
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Posted by Gregory Shimansky <gs...@gmail.com>.
On Sunday 12 November 2006 00:39 Geir Magnusson Jr. wrote:
> > Ok I think I've come up with a reasonable compromise. I still used the
> > whole system of converting XML and all the stuff. It does quite a lot of
> > things in setup and init targets and using <select> is convenient. I
> > don't know how to untangle all of the setup and not do a lot of
> > duplication in ant scripting which I am not big expert in.
>
> Why? Why do we want to persist with this system, when WE ARE GOING TO
> GET RID OF IT at some point?
One reason would be is that I don't know ant well enough to redesign the whole
stuff all together. I used the existing setup and init targets which take
care of including ancontrip and cctask jars.
If you ask me, I'd prefer make in the first place, ant is just too foreign to
me. There is no reason to use caps, we didn't even start to discuss how we
want to see drlvm build and "when WE ARE GOING TO GET RID OF IT at some
point".
> Did you also fix the silliness of having to use annotations to exclude
> tests? Please? :)
No, the patch has an exclude example using and <exclude> statement in
patternset in its beginning.
> I'm glad we have these tests, but really... I wish you hadn't invested
> the time integrating it into the DRLVM build system...
Even if we write a new one from scratch I want the tests right now. There were
several times when JVMTI was broken since there were no tests for it at all
since it is a special VM mode no one usually uses.
The time invested, well... I learned a lot since the last time I used ant.
Maybe one day I'll be able to write something as impressive and
unmaintainable as the current drlvm built :)
Seriously, if we're going to change it, let's discuss it how we want it to
look like and which tool we'll use. I vote for make (gnu version, that is
gmake), even on win32 it exists in cygwin and mingw.
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Posted by Alexei Fedotov <al...@gmail.com>.
Gregory,
I have checked the patch. I like it. Here are few notes.
* When I used ant there were no <for> tag [1]. I used autogenerated
ant files to run something in a loop. Solution with <for> takes less
place and is more readable.
* From my perspective 3 min timeout for a smoke test should be
decreased. I think there should be no stress/reliaiblity loads during
acceptance testing. The reason is simple: complex loads demonstrate
unpredicable behavior and do not reveal problems with 100% accuracy,
so the bad patch pass such acceptance tests sooner or later.
* As for TestNG concern, I don't think we need to stick to the
harness. When the time comes, we will change the harness painlessly.
1. http://mail-archives.apache.org/mod_mbox/ant-user/200410.mbox/%3COF8CC74784.BD58C762-ON80256F24.0036DE55-80256F24.003D7542@db.com%3E
On 11/10/06, Gregory Shimansky <gs...@gmail.com> wrote:
> On Thursday 02 November 2006 23:24 Geir Magnusson Jr. wrote:
> > That's an understatement. Don't feel bad. I've never seen anything
> > like it before. The idea of generating ant scripts on teh fly is very
> > unconventional.
>
> .....
>
> > You don't have enough cuts and bruises from working with the DRLVM build :)
>
> Ok I think I've come up with a reasonable compromise. I still used the whole
> system of converting XML and all the stuff. It does quite a lot of things in
> setup and init targets and using <select> is convenient. I don't know how to
> untangle all of the setup and not do a lot of duplication in ant scripting
> which I am not big expert in.
>
> But I managed to cut away the loop over components looking at how "test"
> target in build.xml is written. I've also converted smoke.test target to the
> same way because both jvmti and smoke tests are meant for a whole VM, not
> some component of it. This also made a weird bug go away when of smoke tests
> were built and run in some random subdirectory of "semis" instead of being
> in "vm" when they were ran separately as "build smoke.test".
>
> Tests should be in their own subdirectories (main test inclusion/exclusion
> loop is done over them), main Java class for application has to be equal to
> have package and name equal to its subdirectory. Otherwise the build system
> won't know what to run. Other files may have any kind of names.
>
> I wrote one simple JVMTI test to start the suite. Other tests which I've
> experimented with I cannot submit because I didn't write them. I think
> they'll appear later from JIRAs like one in HARMONY-2143 which were submitted
> to ASF. Take a look at HARMONY-2151 and say what you think. If I don't get
> much opposition I'll commit the patch on this weekend.
>
> Don't shoot me. Writing even that much of Ant took a lot of time, beer and
> hair on my head. I said I am not an ant guru, didn't I?
>
> --
> Gregory Shimansky, Intel Middleware Products Division
>
--
Thank you,
Alexei
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit
checks
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> On Thursday 02 November 2006 23:24 Geir Magnusson Jr. wrote:
>> That's an understatement. Don't feel bad. I've never seen anything
>> like it before. The idea of generating ant scripts on teh fly is very
>> unconventional.
>
> .....
>
>> You don't have enough cuts and bruises from working with the DRLVM build :)
>
> Ok I think I've come up with a reasonable compromise. I still used the whole
> system of converting XML and all the stuff. It does quite a lot of things in
> setup and init targets and using <select> is convenient. I don't know how to
> untangle all of the setup and not do a lot of duplication in ant scripting
> which I am not big expert in.
Why? Why do we want to persist with this system, when WE ARE GOING TO
GET RID OF IT at some point?
>
> But I managed to cut away the loop over components looking at how "test"
> target in build.xml is written. I've also converted smoke.test target to the
> same way because both jvmti and smoke tests are meant for a whole VM, not
> some component of it. This also made a weird bug go away when of smoke tests
> were built and run in some random subdirectory of "semis" instead of being
> in "vm" when they were ran separately as "build smoke.test".
Did you also fix the silliness of having to use annotations to exclude
tests? Please? :)
>
> Tests should be in their own subdirectories (main test inclusion/exclusion
> loop is done over them), main Java class for application has to be equal to
> have package and name equal to its subdirectory. Otherwise the build system
> won't know what to run. Other files may have any kind of names.
>
> I wrote one simple JVMTI test to start the suite. Other tests which I've
> experimented with I cannot submit because I didn't write them. I think
> they'll appear later from JIRAs like one in HARMONY-2143 which were submitted
> to ASF. Take a look at HARMONY-2151 and say what you think. If I don't get
> much opposition I'll commit the patch on this weekend.
>
> Don't shoot me. Writing even that much of Ant took a lot of time, beer and
> hair on my head. I said I am not an ant guru, didn't I?
>
I'm glad we have these tests, but really... I wish you hadn't invested
the time integrating it into the DRLVM build system...
geir
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Posted by Gregory Shimansky <gs...@gmail.com>.
On Thursday 02 November 2006 23:24 Geir Magnusson Jr. wrote:
> That's an understatement. Don't feel bad. I've never seen anything
> like it before. The idea of generating ant scripts on teh fly is very
> unconventional.
.....
> You don't have enough cuts and bruises from working with the DRLVM build :)
Ok I think I've come up with a reasonable compromise. I still used the whole
system of converting XML and all the stuff. It does quite a lot of things in
setup and init targets and using <select> is convenient. I don't know how to
untangle all of the setup and not do a lot of duplication in ant scripting
which I am not big expert in.
But I managed to cut away the loop over components looking at how "test"
target in build.xml is written. I've also converted smoke.test target to the
same way because both jvmti and smoke tests are meant for a whole VM, not
some component of it. This also made a weird bug go away when of smoke tests
were built and run in some random subdirectory of "semis" instead of being
in "vm" when they were ran separately as "build smoke.test".
Tests should be in their own subdirectories (main test inclusion/exclusion
loop is done over them), main Java class for application has to be equal to
have package and name equal to its subdirectory. Otherwise the build system
won't know what to run. Other files may have any kind of names.
I wrote one simple JVMTI test to start the suite. Other tests which I've
experimented with I cannot submit because I didn't write them. I think
they'll appear later from JIRAs like one in HARMONY-2143 which were submitted
to ASF. Take a look at HARMONY-2151 and say what you think. If I don't get
much opposition I'll commit the patch on this weekend.
Don't shoot me. Writing even that much of Ant took a lot of time, beer and
hair on my head. I said I am not an ant guru, didn't I?
--
Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit
checks
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Gregory Shimansky wrote:
> Geir Magnusson Jr. wrote:
>>
>>
>> Gregory Shimansky wrote:
>>> Geir
>>>
>>> I actually was serious. Probably you were confused, I didn't write
>>> "build test", I wrote "build smoke.test". The first one works ok, the
>>> second doesn't.
>>>
>>> It happens because "test" (top-level test target) is handled in a
>>> different way from "smoke.test" (target just for smoke test category)
>>> target in build.xml. The "smoke.test" target just switches default
>>> processing target to "smoke.test" and runs "process_components"
>>> (which in its turn loops over all components). The "test" special
>>> handling of processing components escapes me, I don't quite
>>> understand how it works, but it seems to work correctly, without
>>> looping.
>>
>> I've used them both, and targetted smoke for specific use cases (opt,
>> etc)
>
> Hmm you probably know more about VM build than I do since you've been
> modifying it for quite some time already. I've just started to look into
> the whole thing.
>
>>>
>>> The question I was trying to solve was, how to correctly add
>>> jvmti.test target to the build.xml so that it would run only jvmti
>>> tests but not loop over components, but when "test" target it called,
>>> jvmti tests category would be executed along with all other categories.
>>>
>>> Including "jvmti.test" target into build.xml in the same way as
>>> "smoke.test" doesn't make me happy.
>>
>> Right - I thought you'd start a revolt and do it outside of the "loop
>> over test types" system we have now.
>
> Well I am not an ant guru, and the current build system definitely
> requires some time to understand.
That's an understatement. Don't feel bad. I've never seen anything
like it before. The idea of generating ant scripts on teh fly is very
unconventional.
> I've tried to copy most of the stuff
> from other test ant files to make my own. I think I'll file a JIRA
> before committing it to make it possible to discuss it.
>
>> In order to keep this simple, why not just have a separate test target
>> for now
>>
>> $ sh build.sh test.jvmti
>>
>> and we can stare at that together, and figure out how to integrate...
>> simplest thing would be to rename the current "test" target to
>> "test_loop" or something, and then
>>
>> <target name="test" depends="test_loop, test.jvmti" />
>>
>> :)
>
> Hmm good idea, why didn't I think of it myself?... :)
>
You don't have enough cuts and bruises from working with the DRLVM build :)
geir