You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/07/21 16:11:57 UTC
Re: [build-test-infra] Build Test Infrastructure
On 21 July 2006 at 9:09, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
> Vladimir Ivanov wrote:
> > I tried to use it. It is OK, but I have some comments on it. First of all,
> > let me describe as I see the testing process:
> >
> > - for developers:
> > Before the commit of new feature/ fix the developer should run some
> > 'pre-integration tests' (it may be unit tests) to be sure that workspace
> > will not broken by commit. If developer have more than 1 platform it will
> > nice to run these tests on different platforms.
> > It is a base testing infrastructure for any project and Harmony already has
> > it (for both - vm and api).
>
> That is the assumption, right? Every developer should already be doing
> this.
>
> >
> > Also, the "cruise control" systems on the target platforms over
> > 'pre-integration tests' will be very useful just to check that the current
> > workspace is OK (not all developers can check fixes on all target
> > platforms).
>
> Right
>
> >
> > - for other community members (all peoples who want to help):
> > If somebody wants to help to run tests he should download only the binary
> > form of HDK, tests and script(s) to run it. Than he run all tests and
> > upload/ emails results back. Of cause, these scripts should require minimum
> > external tools (for example, 'ant' only).
> > It is may be one time action for this member or time-to-time (depends on
> > his
> > wishes).
> >
> > In this context seems a little bit discourteous to ask users to use the
> > cruise control, svn, c/c++ compilers etc to run Harmony tests. On other
> > side, for developers your system is a little bit excessive.
>
> I don't agree that it's so black and white. There's a valid point in
> that some people might want to volunteer to run things, and that we can
> minimize the tooling requirements. But that can be solved easily :
>
> 1) we produce a snapshot of buildtest/
> 2) we add another configuration that fetches an HDK and runs the tests
>
> (Actually, this is a good idea, and I look forward to seeing your patch!)
>
> Seriously, that's not a bad idea, and it would only require having ant
> and Java. No need for SVN or other tools.
I was planning to jar up tests from modules just as I have with the test
support classes (in build/test/support.jar) and I'd expect those to
remain in the hdk.
Adding an ant script to run the tests would not be trivial - due to the
api/impl/bootclasspath/etc issues - but should be possible.
-Mark.
> >
> > - for testing engineer (or somebody from developers):
> > Looking through the result reports for different platforms, tries to
> > reproduce detected failures and propose fixes for them.
> >
> > Of cause, it is my thoughts only and may be it does not true, but I want to
> > try to prepare testing scripts based on HDK (or snapshots of workspace) and
> > tests archives.
>
> it's not an either-or though. See if you can consider using the
> testbuild config - with a combination of a new ant target and different
> config for CC - that does what you suggest - fetches the HDK and runs
> against it..
>
> geir
>
> >
> > Thanks, Vladimir
> > On 7/12/06, Geir Magnusson Jr < geir@pobox.com> wrote:
> >>
> >>
> >>
> >> Alex Blewitt wrote:
> >> > FWIW Mac OS X doesn't have tools.jar in $JAVA_HOME/lib. Instead, the
> >> > tools are in the classes.jar file (no, it's not called rt.jar either)
> >> > in $JAVA_HOME/../Classes/classes.jar. It's a bit unfortunate that it
> >> > has both the run-time libraries and the tools in one place, but
> >> > essentially it means that the sun tools are on the classpath whatever
> >> > happens.
> >> >
> >> > Not that it's spectacularly relevant, but I thought I'd mention it
> >> > here in case there's going to be a Mac port in the future ...
> >>
> >> What do you mean "in case"? :) I'm hoping we can do that sooner rather
> >> than later...
> >>
> >> geir
> >>
> >> >
> >> > Alex.
> >> >
> >> >
> >> > On 11/07/06, Geir Magnusson Jr < geir@pobox.com> wrote:
> >> >>
> >> >>
> >> >> Richard Liang wrote:
> >> >> >
> >> >> > It seems that JAVA_HOME is required by cc/cruisecontrol.sh on my
> >> Ubuntu
> >> >> > :-) Do I miss something? Thanks a lot.
> >> >>
> >> >> That seems to be the case :) If you set it, does it work?
> >> >>
> >> >> It seems to want it for two things, tools.jar (for it's JSPs?) and
> >> where
> >> >> to find java executable. The latter we just deal with (expect it
> >> to be
> >>
> >> >> on the executable path), but tools is more interesting....
> >> >>
> >> >> geir
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >> >>
> >> >>
> >> >
> >> > ---------------------------------------------------------------------
> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >> >
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [build-test-infra] Build Test Infrastructure
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Vladimir Ivanov wrote:
> On 7/26/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>
>>
>> We already have a script for building the HDK and JRE. The publishing
>> part should be fairly straightforward. I imagine we'll have volunteers
>> that produce the designated nightly snapshots for a given platform so we
>> can get the widest variety of OS/chipset as possible.
>
>
>
> Could you commit these scripts to the 'buildtest' module?
I'll certainly take a look.
> I'm a volunteer to produce this snapshot for WinXP.
Ok - great.
geir
>
> Thanks, Vladimir
>
>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [build-test-infra] Build Test Infrastructure
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 7/26/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
>
> We already have a script for building the HDK and JRE. The publishing
> part should be fairly straightforward. I imagine we'll have volunteers
> that produce the designated nightly snapshots for a given platform so we
> can get the widest variety of OS/chipset as possible.
Could you commit these scripts to the 'buildtest' module?
I'm a volunteer to produce this snapshot for WinXP.
Thanks, Vladimir
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [build-test-infra] Build Test Infrastructure
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Vladimir Ivanov wrote:
> On 7/26/06, Geir Magnusson Jr < geir@pobox.com> wrote:
>>
>>
>>
>>
>> That's what the buildtest subproject is for. Have you looked at it?
>
>
>
> Yes. When I tried to run it for the first time I saw problems with <get>
> and
> <svn> commands - they did not work in my environment due to:
> - no proxy settings for <get> and <exec svn> command.
> - some problems with my certificate for apache site.
Ok - those all are local issues for you ;) We should parametrize what
we can though for others.
>
> I propose to do the following:
> - specify in README.txt that if you work via proxy, then, specify in
> property file values for proxy host/port and checks proxy settings into
> your
> SVN configuration files.
Yep.
> - specify in README.txt that the certificate to work with apache site
> should be accepted.
>
> Does it make sense?
I see no such problems w/ the certificate. Does your cacerts not have
the root cert for whatever our CA is? (I forget what it is..)
> Issue 995 was created to support proxy settings for the 'get' target.
Thanks!
>
>
>
>> > 4. Full testing - the whole set of Harmony tests are run on
>> regular
>> > builds, results are published.
>> > Goal: to see what happened with Harmony quality on the whole set of
>> > automated tests, see new bugs, see quality of Harmony runtimes.
>> > Users should be able to do this kind of testing on their specific
>> platforms
>> > and publish results on Harmony web site.
>> > ****This script (prototype) I implemented, see issue 984.
>>
>> I thought that the classlib tests are run as well w/ the CC script right
>> now, but will check.
>
>
> Yes, but I hope in the future we will have more test suites (functional,
> stress etc).
> Will we run all of them in code integrity testing? – I suppose no, once we
> see that running all tests takes more then hour.
I certainly want to hook them into the standard CI framework, and we
just choose what set gets run. I have a new machine coming, and I'll
run anything and everything 24 hours a day.
geir
>
> Thanks, Vladimir
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [build-test-infra] Build Test Infrastructure
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 7/26/06, Geir Magnusson Jr < geir@pobox.com> wrote:
>
>
>
>
> That's what the buildtest subproject is for. Have you looked at it?
Yes. When I tried to run it for the first time I saw problems with <get> and
<svn> commands - they did not work in my environment due to:
- no proxy settings for <get> and <exec svn> command.
- some problems with my certificate for apache site.
I propose to do the following:
- specify in README.txt that if you work via proxy, then, specify in
property file values for proxy host/port and checks proxy settings into your
SVN configuration files.
- specify in README.txt that the certificate to work with apache site
should be accepted.
Does it make sense?
Issue 995 was created to support proxy settings for the 'get' target.
> > 4. Full testing - the whole set of Harmony tests are run on
> regular
> > builds, results are published.
> > Goal: to see what happened with Harmony quality on the whole set of
> > automated tests, see new bugs, see quality of Harmony runtimes.
> > Users should be able to do this kind of testing on their specific
> platforms
> > and publish results on Harmony web site.
> > ****This script (prototype) I implemented, see issue 984.
>
> I thought that the classlib tests are run as well w/ the CC script right
> now, but will check.
Yes, but I hope in the future we will have more test suites (functional,
stress etc).
Will we run all of them in code integrity testing? – I suppose no, once we
see that running all tests takes more then hour.
Thanks, Vladimir
Re: [build-test-infra] Build Test Infrastructure
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Vladimir Ivanov wrote:
> The more I go further with build&testing infrastructure and think about it
> the more the following overall picture is drawing in my mind.
> Let me share it to see the whole picture and what I see should be next in
> build and testing infrastructure:
>
> Goal: Harmony quality
> Objectives:
> - Set-up regular building & build publishing process
Yep
> - Set-up testing process, which:
> - Provides code integrity (Harmony can be built at each moment of
> time), regressions are seen immediately.
Yep. We now have a "proprietary" one running at IBM, for which we are
grateful. The buildtest subproject in Harmony is meant to replace this
at some point and we all will run it.
> - Done by both at Harmony hosting site and by community members.
> - Is easy to set-up and run.
> - Results of testing on community member's platforms can be
> published.
> - History of test failures, build quality can be tracked.
Yes
>
> Builds.
> Lets consider the following:
> 1. Regular (daily, weekly?) building of JRE and HDK and tests.
daily snapshot
> Goal: being regularly published, one can just download and run / test them
> without need to download sources, tools and building Harmony themselves.
> What we need to be built and published? – I suppose we can start with:
> - Harmony API + DRLVM
> - Harmony API + J9
> - Harmony API + JCHVM
> - API unit tests
I would suggest :
HDK (classlib + unit tests)
JDK/JRE (classlib + DRLVM)
and once JCHEVM uses either the classlib or the glue layer is finished,
a JDK/JRE with that.
We won't create anything w/ J9 in it (as that's IBMs proprietary code)
and anyone who wishes to use it can take the HDK and drop J9 right in
very easily.
That said, I do think we still want people to be independently running
(as part fo the test loop) Classlib + J9 because testing with the broad
variety of VMs available to us will is useful.
>
> Do we want to provide capabilities for people to install "build tool" and
> have Harmony built regularly on their platforms? – I guess yes.
Yes - that is the point of the buildtest/ project.
>
> ****I can (and plan) do a simple ant script for building and archiving
> binaries (If no objection).
We already have a script for building the HDK and JRE. The publishing
part should be fairly straightforward. I imagine we'll have volunteers
that produce the designated nightly snapshots for a given platform so we
can get the widest variety of OS/chipset as possible.
> Once it is done, I can start publishing the binaries more or less regularly
> at some site and provide links at our wiki pages – is it worth doing?
We would put them in the snapshot directory that we use now.
http://people.apache.org/dist/incubator/harmony/snapshots/
>
> 2. We establish continuous building to make sure we have consistent
> workspace. Cruise Control is OK for this purpose.
> What we build:
> - Harmony API
> - DRLVM
> - JCHVM
>
> Do we want to provide capabilities for people to install and have "Cruise
> Control – based tool" running on their platforms? – I guess yes (correct me
> if I'm wrong), in case if somebody is interested in keeping Harmony
> buildable and runnable on his favorite platform (FreeBSD, for example).
That's what the buildtest subproject is for. Have you looked at it?
>
> Testing.
> I would propose to consider the following levels of testing.
> 1. Pre-integration testing – quickly executed set of tests to be run
> to make sure a patch does not worsen Harmony quality.
> Goal: for a community member or committer to check that the patch does not
> worsen Harmony quality.
>
> ****This is already discussed, agreed and implemented for both API and VM.
> Do we need something more to be done here?
I hope not.
>
> 2. Code integrity testing – done by regular often building of Harmony
> components by Cruise Control.
> Goal: to make sure no "compilation errors" were introduced by recent
> commits, if introduced, then, notification along with list of recent
> commits
> is sent to all.
>
> ****This is what is done recently by Geir by Cruise Control script.
Yes, I am doing it, but the goal isn't to have only one person doing it.
The goal of the buildtest/ subproject
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/buildtest/trunk
is to help *anyone* that wants to help to easily checkout the system,
have it auto-setup as much as possible, and then just run.
What remains to be worked out is the email and notification aggregation,
so that we can have a "dashboard" or matrix of all the platforms being
tested, with their current status and history. This is an important
thing to get done, and I'm hoping someone volunteers.
>
> 3. Smoke testing – a number of tests should be run over received via
> Cruise Control build.
> Goal: to make sure no regressions were introduced by recent commits, the
> built runtime can do its basic operations.
> If regression is introduced, then, notification along with list of recent
> commits is sent to all.
> ****This is what is done recently by Geir in Cruise Control script.
Right
>
> 4. Full testing - the whole set of Harmony tests are run on regular
> builds, results are published.
> Goal: to see what happened with Harmony quality on the whole set of
> automated tests, see new bugs, see quality of Harmony runtimes.
> Users should be able to do this kind of testing on their specific platforms
> and publish results on Harmony web site.
> ****This script (prototype) I implemented, see issue 984.
I thought that the classlib tests are run as well w/ the CC script right
now, but will check.
>
> 5. Application testing – people enable applications, try already
> enabled applications on fresh builds, publish results.
> Goal: to see what happened with Harmony quality on various applications
> people like.
> We can start from having a wiki page (which partially exists in some form)
> on which community publishes results of running applications on various
> Harmony builds.
> ****Do we need here more?
Maybe eventually we'll want to automate. We certainly want to get Gump
runs going too for this.
> 6. [optional] Reliability testing – either special reliability tests
> or some applications are executed during long time (from one regular build
> to another).
> Goal: to make sure we have reliable, stable, long running runtime.
> For future.
>
> thanks, Vladimir
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [build-test-infra] Build Test Infrastructure
Posted by Vladimir Ivanov <iv...@gmail.com>.
The more I go further with build&testing infrastructure and think about it
the more the following overall picture is drawing in my mind.
Let me share it to see the whole picture and what I see should be next in
build and testing infrastructure:
Goal: Harmony quality
Objectives:
- Set-up regular building & build publishing process
- Set-up testing process, which:
- Provides code integrity (Harmony can be built at each moment of
time), regressions are seen immediately.
- Done by both at Harmony hosting site and by community members.
- Is easy to set-up and run.
- Results of testing on community member's platforms can be
published.
- History of test failures, build quality can be tracked.
Builds.
Lets consider the following:
1. Regular (daily, weekly?) building of JRE and HDK and tests.
Goal: being regularly published, one can just download and run / test them
without need to download sources, tools and building Harmony themselves.
What we need to be built and published? – I suppose we can start with:
- Harmony API + DRLVM
- Harmony API + J9
- Harmony API + JCHVM
- API unit tests
Do we want to provide capabilities for people to install "build tool" and
have Harmony built regularly on their platforms? – I guess yes.
****I can (and plan) do a simple ant script for building and archiving
binaries (If no objection).
Once it is done, I can start publishing the binaries more or less regularly
at some site and provide links at our wiki pages – is it worth doing?
2. We establish continuous building to make sure we have consistent
workspace. Cruise Control is OK for this purpose.
What we build:
- Harmony API
- DRLVM
- JCHVM
Do we want to provide capabilities for people to install and have "Cruise
Control – based tool" running on their platforms? – I guess yes (correct me
if I'm wrong), in case if somebody is interested in keeping Harmony
buildable and runnable on his favorite platform (FreeBSD, for example).
Testing.
I would propose to consider the following levels of testing.
1. Pre-integration testing – quickly executed set of tests to be run
to make sure a patch does not worsen Harmony quality.
Goal: for a community member or committer to check that the patch does not
worsen Harmony quality.
****This is already discussed, agreed and implemented for both API and VM.
Do we need something more to be done here?
2. Code integrity testing – done by regular often building of Harmony
components by Cruise Control.
Goal: to make sure no "compilation errors" were introduced by recent
commits, if introduced, then, notification along with list of recent commits
is sent to all.
****This is what is done recently by Geir by Cruise Control script.
3. Smoke testing – a number of tests should be run over received via
Cruise Control build.
Goal: to make sure no regressions were introduced by recent commits, the
built runtime can do its basic operations.
If regression is introduced, then, notification along with list of recent
commits is sent to all.
****This is what is done recently by Geir in Cruise Control script.
4. Full testing - the whole set of Harmony tests are run on regular
builds, results are published.
Goal: to see what happened with Harmony quality on the whole set of
automated tests, see new bugs, see quality of Harmony runtimes.
Users should be able to do this kind of testing on their specific platforms
and publish results on Harmony web site.
****This script (prototype) I implemented, see issue 984.
5. Application testing – people enable applications, try already
enabled applications on fresh builds, publish results.
Goal: to see what happened with Harmony quality on various applications
people like.
We can start from having a wiki page (which partially exists in some form)
on which community publishes results of running applications on various
Harmony builds.
****Do we need here more?
6. [optional] Reliability testing – either special reliability tests
or some applications are executed during long time (from one regular build
to another).
Goal: to make sure we have reliable, stable, long running runtime.
For future.
thanks, Vladimir
Re: [build-test-infra] Build Test Infrastructure
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 7/29/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
>
> That's not what the HDK is intended for. (I was afraid of this when it
> was named... I also ran into the same thing explaining it to people
> this week...
>
> The HDK is not analogous to the JDK - it's really an SDK to assist in
> the development of Harmony, where the JDK is an SDK for the development
> of Java programs.
>
> geir
Seems I was misleading by name. Of course, in this context tests should be a
part of HDK.
thanks, Vladimir
Re: [build-test-infra] Build Test Infrastructure
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Vladimir Ivanov wrote:
> On 7/26/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>>
>>
>> ...
>>
>> Who would want to use HDK and not run tests? I would assume you'd want
>> to run tests of other modules that depend on the thing you are working
>> on.
>>
>>
>> geir
>
>
>
> I use SUN and BEA JDK's and both were without tests (but with demo's). I
> think if HDK is like to JDK (designed for application development) than
> tests for HDK should be built as separated bundle to minimize user's
> traffic.
That's not what the HDK is intended for. (I was afraid of this when it
was named... I also ran into the same thing explaining it to people
this week...
The HDK is not analogous to the JDK - it's really an SDK to assist in
the development of Harmony, where the JDK is an SDK for the development
of Java programs.
geir
>
>
>
> Thanks, Vladimir
>
>
> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [build-test-infra] Build Test Infrastructure
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 7/26/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
> ...
>
> Who would want to use HDK and not run tests? I would assume you'd want
> to run tests of other modules that depend on the thing you are working on.
>
>
> geir
I use SUN and BEA JDK's and both were without tests (but with demo's). I
think if HDK is like to JDK (designed for application development) than
tests for HDK should be built as separated bundle to minimize user's
traffic.
Thanks, Vladimir
---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>
Re: [build-test-infra] Build Test Infrastructure
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Vladimir Ivanov wrote:
> On 7/24/06, Vladimir Ivanov <iv...@gmail.com> wrote:
>>
>>
>>
>> On 7/21/06, Mark Hindess < mark.hindess@googlemail.com> wrote:
>> >
>> >
>> > I was planning to jar up tests from modules just as I have with the
>> test
>> > support classes (in build/test/support.jar) and
>>
>>
> I created issue 984 with simple patch that jars modules/<name>/bin/test
> directories.
> May be it makes sense to build 3 separate archives: HDK, JRE and tests to
> minimize traffic for users who want to use HDK but do not want to run
> tests?
Who would want to use HDK and not run tests? I would assume you'd want
to run tests of other modules that depend on the thing you are working on.
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org
Re: [build-test-infra] Build Test Infrastructure
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 7/24/06, Vladimir Ivanov <iv...@gmail.com> wrote:
>
>
>
> On 7/21/06, Mark Hindess < mark.hindess@googlemail.com> wrote:
> >
> >
> > I was planning to jar up tests from modules just as I have with the test
> > support classes (in build/test/support.jar) and
>
>
I created issue 984 with simple patch that jars modules/<name>/bin/test
directories.
May be it makes sense to build 3 separate archives: HDK, JRE and tests to
minimize traffic for users who want to use HDK but do not want to run tests?
thanks, Vladimir
I'd expect those to
> > remain in the hdk.
>
>
> Seems, that it will enough to pack all modules\<name>\bin\test
> directories into one jar
>
>
> Adding an ant script to run the tests would not be trivial - due to the
> > api/impl/bootclasspath/etc issues - but should be possible.
>
>
> It is script harmony specific so no difference between 'api' and 'impl'
> tests.
> So I just separate tests run to 2:
> - for 'injected' tests
> - for common tests
>
> May be I miss something?
> thanks, Vladimir
>
> -Mark.
> >
> > Thanks, Vladimir
> >
>
Re: [build-test-infra] Build Test Infrastructure
Posted by Vladimir Ivanov <iv...@gmail.com>.
On 7/21/06, Mark Hindess <ma...@googlemail.com> wrote:
>
>
> I was planning to jar up tests from modules just as I have with the test
> support classes (in build/test/support.jar) and I'd expect those to
> remain in the hdk.
Seems, that it will enough to pack all modules\<name>\bin\test directories
into one jar
Adding an ant script to run the tests would not be trivial - due to the
> api/impl/bootclasspath/etc issues - but should be possible.
It is script harmony specific so no difference between 'api' and 'impl'
tests.
So I just separate tests run to 2:
- for 'injected' tests
- for common tests
May be I miss something?
thanks, Vladimir
-Mark.
>
> Thanks, Vladimir
>