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/10/03 09:02:41 UTC
Re: [general] jre and hdk snapshots posted to general snapshot site
On 2 October 2006 at 16:36, Oliver Deakin <ol...@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 <iv...@gmail.com>:
> >> On 9/27/06, Geir Magnusson Jr. <ge...@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 <ge...@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
Re: [general] jre and hdk snapshots posted to general snapshot site
Posted by Tim Ellison <t....@gmail.com>.
sorry for the late reply...
Oliver Deakin wrote:
> I see - sorry, I was getting my API/impl/injected jargon mixed up.
> Really I was thinking about
> the distinction between tests that run on the bootclasspath (injected)
> and those that dont, rather
> than between the publicly spec'ed classes (api) and our internal
> implementations (impl).
>
> I agree that we may need 4 jars for the most complicated modules. I
> don't see this as a problem
> myself - as long as they are clearly named I don't think the number of
> jars is an issue.
I disagree. We should not confuse the physical packaging of the test
code in JARs with the grouping of tests between API and Impl (and
platform-specific and VM-specific etc, etc).
We need to package separately only so we can install types on the
bootclasspath (bcp) vs. the application classpath (cp). We use the
any-day-now test metadata to group the types of tests. So we will only
ever need two JARs per module, the 'foo-tests-bcp.jar' and the
'foo-tests-cp.jar'.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
---------------------------------------------------------------------
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: [general] jre and hdk snapshots posted to general snapshot site
Posted by Oliver Deakin <ol...@googlemail.com>.
Mark Hindess wrote:
> On 2 October 2006 at 16:36, Oliver Deakin <ol...@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. ;-)
>
oops, yes I see that now - just me catching up with my email backlog.
Almost there...
> 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!
>
I see - sorry, I was getting my API/impl/injected jargon mixed up.
Really I was thinking about
the distinction between tests that run on the bootclasspath (injected)
and those that dont, rather
than between the publicly spec'ed classes (api) and our internal
implementations (impl).
I agree that we may need 4 jars for the most complicated modules. I
don't see this as a problem
myself - as long as they are clearly named I don't think the number of
jars is an issue.
I presume they will reside somewhere like <hdk>/test?
Regards,
Oliver
> -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 <iv...@gmail.com>:
>>>
>>>> On 9/27/06, Geir Magnusson Jr. <ge...@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 <ge...@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
>
>
>
--
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