Geir As you can see [1] there is a consensus that x-security (or auth or x-auth - as you want) should be separated from general security.
So I think the following packages could be moved to a separate module: javax.security.* w/o javax.security.cert org.ietf Thanks, Mikhail [1]. http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] On 2/13/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > When you quote someone, please indicate at least who it is. > > Stepan Mishura wrote: > >>> 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 > >>> > > >
