Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
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
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
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: [classlib:security2] bootclasspath for security tests [HARMONY-58]
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
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
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 [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
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
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 [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
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
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]
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 [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
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
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?
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 [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
Re: [classlib:security2] bootclasspath for security tests [HARMONY-58]
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]
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 [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
