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.
This is the right approach.
A while ago I took the old security2 build script and rewrote it to do a
LUNI build this way (also factoring out the platform-specific parts to
make it extensible). Now I'm using Eclipse and got lazy ;-)
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.