You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Geir Magnusson Jr <ge...@pobox.com> on 2006/02/09 01:30:00 UTC
[classlib:security2] bootclasspath for security tests [HARMONY-58]
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
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
>
> 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 ;-)
I was really trying to use Eclipse, but last night it couldn't do the
simplest bit of refactoring. I was doing class renaming (to get rid of
the random test naming in security2) and it just had some problem, and
told me to look at the log. What log? A log?
So I started IDEA and kept going....
I'll try to go back once I cool down. While I'm here though I'll see
about getting IDEA to use Harmony...
geir
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Tim Ellison <t....@gmail.com>.
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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Stepan Mishura <st...@gmail.com>.
I agree that we should separate API that provides authorization,
authentication and secure communication into a standalone module.
If there will be no objections I'm going to create a JIRA task to do
separation.
Thanks,
Stepan
On 2/15/06, Mikhail Loenko <mloenko <at> gmail.com> wrote:
>
> 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 <ge...@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 <ge...@pobox.com> wrote:
> > >>
> > >>
> > >> Stepan Mishura wrote:
> > >>> On 2/9/06, Geir Magnusson Jr <ge...@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.jarand
> > >>>> 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 <ge...@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
> > >>>
> > >
> >
>
--
Thanks,
Stepan Mishura
Intel Middleware Products Division
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Mikhail Loenko <ml...@gmail.com>.
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 <ge...@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 <ge...@pobox.com> wrote:
> >>
> >>
> >> Stepan Mishura wrote:
> >>> On 2/9/06, Geir Magnusson Jr <ge...@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 <ge...@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
> >>>
> >
>
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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 <ge...@pobox.com> wrote:
>>
>>
>> Stepan Mishura wrote:
>>> On 2/9/06, Geir Magnusson Jr <ge...@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 <ge...@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
>>>
>
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Stepan Mishura <st...@gmail.com>.
>>
>> 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 <ge...@pobox.com> wrote:
>
>
>
> Stepan Mishura wrote:
> > On 2/9/06, Geir Magnusson Jr <ge...@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 <ge...@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
> >
>
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Stepan Mishura wrote:
> On 2/9/06, Geir Magnusson Jr <ge...@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 <ge...@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
>
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Stepan Mishura <st...@gmail.com>.
On 2/9/06, Geir Magnusson Jr <ge...@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?
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.
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?
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 <ge...@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
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Geir Magnusson Jr 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?
>
> s/bootclasspath/jre\/lib\/boot directory/ ?
yes, of course. sorry
>
>>> 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?
>
> yep
>
>>> 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?
>
> erm, 'yes' -- I mean 'no', erm -- what's the question?
>
> the JARs should be on the bootclasspath by being built into jre/lib/boot.
>
> Please remember to include the manifest too, the current security.jar
> does not have one and breaks my Eclipse development (I can raise a JIRA
> to say that if you want).
Heh. Ok. I'll do now. If I forget, then drop in a JIRA...
>
> Regards,
> Tim
>
>>> On 2/9/06, Geir Magnusson Jr <ge...@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
>>>>>
>>>>>
>
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr 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?
s/bootclasspath/jre\/lib\/boot directory/ ?
>> 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?
yep
>> 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?
erm, 'yes' -- I mean 'no', erm -- what's the question?
the JARs should be on the bootclasspath by being built into jre/lib/boot.
Please remember to include the manifest too, the current security.jar
does not have one and breaks my Eclipse development (I can raise a JIRA
to say that if you want).
Regards,
Tim
>> On 2/9/06, Geir Magnusson Jr <ge...@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
>>>>
>>>>
>>
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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?
>
> 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 <ge...@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
>>>
>>>
>
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Stepan Mishura <st...@gmail.com>.
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 <ge...@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
> >
> >
>
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
Posted by Geir Magnusson Jr <ge...@pobox.com>.
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
>
>