harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stepan Mishura <stepan.mish...@gmail.com>
Subject Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Date Mon, 13 Feb 2006 11:43:43 GMT
>>
>> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message