harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikhail Loenko <mloe...@gmail.com>
Subject Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Date Wed, 15 Feb 2006 05:38:45 GMT
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/%3c43F0B9E9.5000707@gmail.com%3e

On 2/13/06, Geir Magnusson Jr <geir@pobox.com> 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/%3c43D9FB67.7020605@pobox.com%3e
> > )
> >
> > 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 <geir@pobox.com> wrote:
> >>
> >>
> >> Stepan Mishura wrote:
> >>> 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?
> >> 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 <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
View raw message