Alexei Zakharov wrote:
If we plan to use HDK for supporting developers who work on single
module (that is a good idea IMHO) then we definitely need to supply
jar with tests.
Can I suggest that we have a separate test jar for each module? So
we'd have luni-tests.jar, security-tests.jar etc. This means that if a
developer
working on a single module creates a bug fix and a new test case, they only
need to rebuild the test jar for that particular module (they may only
have that single
module checked out, after all).
In fact, we will need to create separate test jars for bootclasspath and
classpath
tests, unless there is a way in Ant to specify which subsets of the file
tree within
a jar are on the bootclasspath/classpath - it's probably simpler to just
have
<module>-api-tests.jar and <module>-impl-tests.jar (or whatever naming
convention).
So IMHO we should:
1) Add bundling of <module>-<type>-tests.jar into the HDK to each module's
build.xml as a standard step of the test build process.
2) Alter the test execution Ant targets to always run the tests using
the prebuilt
<module>-<type>-test.jar's on the (boot)classpath - on the bootclasspath
we put "*-impl-test.jar" and on the classpath we put "*-api-test.jar".
This way running the tests against a prebuilt HDK will work without
rebuilding any
tests (because the test run targets will only expect the prebuilt jars)
and the
developer can easily rebuild a single module's set of tests by running its
compile-tests target (or something similar).
Does this sound reasonable?
Regards,
Oliver
We may also supply the build file with placeholders
for user classes & tests dirs that will be prepended to
classpath/bootclasspath.
Regards,
2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>:
On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
>
> If I recall, the point of the test.jar was to have a pre-built jar of
> tests in the HDK so that someone could setup the build-test infra
> using the HDK so they could run tests on their platform w/o having to
> build everything. Good idea.
Yes, you are correct. This idea implemented in the jira 964.
If that's so, then something would
> have to be configured to have the classlib "test" target use that
> jar. All I'm saying is that how we do this is important, as we don't
> want to cause pain for classlib developers who use the HDK for
> development support.
Seems, we think about different use cases.
In my case, user can download the HDK for own platform (if we have
one) run
tests and look on results (also, may be upload it to the harmony
site). Also
it can be used for application run to check 'enable' status. But if this
user interested in Harmony development he should checkout ws and use
built-in ant targets to build and test updated ws.
How you plan to use HDK? It looks like initial miscommunication :)
thanks, Vladimir
> geir
>
> >
> > Thanks, Vladimir
> >
> >
> >
> >
> >
> >> > Thanks, Vladimir
> >> >
> >> > geir
> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >> > Thanks, Vladimir
> >> >> >
> >> >> >
> >> >> >
> >> >> > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> >> >> >>
> >> >> >> They are at the regular place
> >> >> >>
> >> >> >> http://people.apache.org/dist/incubator/harmony/snapshots
> >> >> >>
> >> >> >> I moved all the old classlib snapshots into /old and I'll
> >> >> update the
> >> >> >> website accordingly. I'll be automating this. Also, lets
not
> >> >> >> make much
> >> >> >> noise about this for a little while so we can test to make
sure
> >> >> >> there's
> >> >> >> no major errors. Things seem good. I have a list of more
> >> >> things to
> >> >> >> fix, but I realized today that I was obsessing over the
> >> snapshot
> >> >> >> contents - it's not a release, and it's "good enough".
> >> >> >>
> >> >> >> I'd like to ditch both /old and the remaining classlib
> >> >> snapshots, as
> >> >> >>
> >> >> >> 1) they are snapshots - history doesn't matter
> >> >> >>
> >> >> >> 2) the classlib is now in the HDK, so we just need to adjust
> >> the
> >> >> >> docs to
> >> >> >> match.
> >> >> >>
> >> >> >> I'll do the latter, but wanted to see if anyone has a problem
> >> >> w/ me
> >> >> >> removing /old and the last classlib snapshot. I'll do this
> >> if I
> >> >> >> don't
> >> >> >> hear any protest, so either positively acknowledge this
action
> >> >> if you
> >> >> >> support it, dont' do a thing if you support or dont' care,
> >> or say
> >> >> >> why we
> >> >> >> shouldn't :)
> >> >> >>
> >> >> >> geir
> >> >> >>
> >> >> >>
> >> >>
> >>
---------------------------------------------------------------------
> >> >> >> Terms of use :
http://incubator.apache.org/harmony/mailing.html
> >> >> >> To unsubscribe, e-mail: harmony-dev-
> >> >> [EMAIL PROTECTED]
> >> >> >> For additional commands, e-mail: harmony-dev-
> >> >> >> [EMAIL PROTECTED]
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
---------------------------------------------------------------------
> >> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> >> To unsubscribe, e-mail: harmony-dev-
> >> [EMAIL PROTECTED]
> >> >> For additional commands, e-mail: harmony-dev-
> >> >> [EMAIL PROTECTED]
> >> >>
> >> >>
> >>
> >>
> >>
---------------------------------------------------------------------
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail:
[EMAIL PROTECTED]
> >> For additional commands, e-mail: harmony-dev-
> >> [EMAIL PROTECTED]
> >>
> >>
>
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
