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 Mon, 13 Feb 2006 12:26:57 GMT
When you quote someone, please indicate at least who it is.

Stepan Mishura wrote:
>>> 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?
>>
> 
> Well, you meant security-x?
> I thought that we agreed on new module name, at least with you :-)
> ( see
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c43D9FB67.7020605@pobox.com%3e
> )
> 
> The discussion about modules reorganization was resumed, and I think we
> should postpone the module extraction for a while until everybody agrees on
> the proposal.
> 
> Thanks,
> Stepan
> 
> 
> On 2/10/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>>
>>
>> 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