harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Date Fri, 10 Feb 2006 12:24:31 GMT


Stepan Mishura wrote:
> On 2/9/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>>
>>
>> Stepan Mishura wrote:
>>> Hi Geir,
>>>
>>>> For the record, I put the jvmarg line back - I did some test class
>>>> renaming, and things broke!  I put it back, and all is well.  Dunno.
>>>> Leaving there so it doesn't break anyone else.  Will continue to chase
>>>> down after dinner
>>>>
>>> crypto.jar and x_net.jar are not created by the 'main build file' (i.e.
>>> make/build.xml) and they are absent in Harmony boot
>> (deploy/jre/lib/boot)
>>> directory. So the build script from 'security2' builds them and places
>>> explicitly to the bootclasspath.
>>
>> Then this is wrong then, correct?  We should put putting crypto.jar and
>> x_net.jar into the bootclasspath?
> 
> As I understood you removed only jvmarg line but didn't update ant script to
> copy generated jar files. So tests failed. Right?

Yes, because we were inconsistent about what we are doing.  Not all jars 
made it to jre/lib/boot

So I've now cut x-net out into a separate module, and will stuff crypto 
into security for now to keep the "1 artifact per module" scheme.

I'm sure we'll cut them apart again at some point in the future.

> 
> The question was how to put required jars in jre/lib/boot directory. A fast
> solution was to copy jars generated with local make file in security2/make.
> And a right solution is to adjust 'security2' to common build structure (i.e.
> make/build.xml) as you did for 'x-net' component. I reviewed your update for
> x-net and I'm ok with it.

Great.  I think that the build will evolve to having to drive the 
general build from the top because of the circular dependencies, and 
then testing being localized to the modules.  I've started on this - 
will have one build-test.xml at the top that calls the individual module 
tests scripts.  Just playing w/ it now - expect more later today.

> 
> I think the similar can be done for 'security-x'. As there are no objections
> for creating the new component I can create a JIRA task for extracting
> 'security-x' from 'security2'. And provide a patch for it by analogy with
> extracting 'x-net'.
> 
> What do you think?

I guess I'm interested in why.  I can see crypto being shaken out, but 
why x-security?

geir

> 
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
> 
>>> If you remove jvmarg line then you need to update additionally
>>> make/build.xml or the build script from 'security2' to put these jars to
>>> Harmony boot directory.
>> Yes - I think that is the sensical way to go as we do want them there,
>> right?
>>
>>> I think that we should work out some kind of 'transition procedure' for
>>> substituting security with security2 to be sure that we don't miss
>> anything
>>> and we are consistent. The first step may be extracting x-net component
>>> because it is quite independent.
>> Don't mix the issues.  Right now, no modules/security code is being built.
>>
>> So - first - any problem with crypto and x_net into bootclasspath?
>>
>> geir
>>
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>
>>> On 2/9/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>>>> For the record, I put the jvmarg line back - I did some test class
>>>> renaming, and things broke!  I put it back, and all is well.  Dunno.
>>>> Leaving there so it doesn't break anyone else.  Will continue to chase
>>>> down after dinner
>>>>
>>>>
>>>> Geir Magnusson Jr wrote:
>>>>> I applied patch for HARMONY-58 (thanks Stepan and Tim) and closed the
>>>>> issue.
>>>>>
>>>>> However, there was a small thing that bugged me.  We were setting the
>>>>> bootclasspath as follows :
>>>>>
>>>>> <jvmarg
>>>>> value="-Xbootclasspath/p:${build.jars.path}/crypto.jar${path.separator
>>>> }${build.jars.path}/x_net.jar"/>
>>>>> which has 2 of the 3 artifacts generated by security2 coming from the
>>>>> local modules/security2 tree, and the third, security.jar, coming from
>>>>> deploy/jre/lib/boot.  This isn't healthy.
>>>>>
>>>>> So I just removed the above line, and now we depend on all three jars
>>>>> coming from the same place, namely the deploy boot classpath.
>>>>>
>>>>> I only feel strongly that we are consistent.  We can change from
>> deploy/
>>>>> to modules/security2 if we need to.
>>>>>
>>>>> I suspect this will be fine, but it does mean that working in
>>>>> modules/security2 means that you need to go to top level to re-run the
>>>>> build to get the jars in the right place.
>>>>>
>>>>> I think I'll change the local make in modules/security2 to also copy
>> the
>>>>> generated jars to ../../deploy/jre/lib/boot/....
>>>>>
>>>>>
>>>>> That way, you can work locally and still do the proper testing w/o
>>>>> having to out of the module you are working in.  I suspect that this
>>>>> will be a pattern we repeat in all modules.
>>>>>
>>>>> geir
>>>>>
>>>>>
> 
> 
> 
> --
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division
> 

Mime
View raw message