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 Fri, 10 Feb 2006 07:00:25 GMT
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?

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.

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?

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