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 Thu, 09 Feb 2006 11:23:20 GMT


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?

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

Mime
View raw message