>> >> 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/[EMAIL PROTECTED] ) 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 <[EMAIL PROTECTED]> wrote: > > > > Stepan Mishura wrote: > > On 2/9/06, Geir Magnusson Jr <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > >
