harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [general] jre and hdk snapshots posted to general snapshot site
Date Fri, 06 Oct 2006 09:13:56 GMT
Mark Hindess wrote:
> 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. ;-)
>   

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 <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
>
>
>   

-- 
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


Mime
View raw message