harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [general] jre and hdk snapshots posted to general snapshot site
Date Tue, 03 Oct 2006 07:02:41 GMT

On 2 October 2006 at 16:36, Oliver Deakin <oliver.deakin@googlemail.com> wrote:
> 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).

It feels like I have an echo.  I said pretty much the same things on the
renamed "Using the HDK" thread earlier in the day. ;-)

I should mention that modules like security actually have four distinct 
types of tests.  api, api.injected, impl, and impl.injected - in other
words some api tests are run on the bootclasspath and some impl tests
are not.

So perhaps we need 4 jars!

-Mark.

> 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 <ivavladimir@gmail.com>:
> >> On 9/27/06, Geir Magnusson Jr. <geir@pobox.com> 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 <geir@pobox.com>
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-
> >> > >> >> 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
> >> >
> >> >
> >>
> >>
> >
> >
> 
> -- 
> Oliver Deakin
> IBM United Kingdom Limited
> 
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message