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?
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
