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 Thu, 09 Feb 2006 07:34:06 GMT
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.

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.

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.

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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message