You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Stepan Mishura <st...@gmail.com> on 2006/01/23 12:07:05 UTC

'security2' TODOs list

Hello,

I'd like to create a list of TODO's to track all issues related to
'security2' module integration. Because it is hard to figure out from many
threads in mailing list what things were done, what blocks us to move
forward and what can be resolved later. Also this list should help us to
understand who took responsibility for a selected item and where we can
help. So here is the summary of issues:

Issues that should be resolved before substituting the current 'security'
module

1) Moving com.openintel to org.apache.harmony (status: almost DONE)
Issues:
- Did we agree on com.openintel.drlx.* -> org.apache.harmony.x.*?
- Tim had problems with running security tests.

2) Integrate build files (status: NONE)
- split 'security2' to components
- compiling native code
- compile and run unit tests

Issues that may be resolved later:

1) Writing JavaDoc (status: the discussion got stuck, no decision was made)
'security2' has "com.intel.drl.spec_ref" javadoc tag that should be replaced


2) New Modules or Components
a. Providers: put providers into separate modules (status: no objections)
See
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c6e47b64f0601170332k3d418fabwd25a264c5e0f1532@mail.gmail.com%3e

b. Do reorg in security component: (status: no replies)
Pick out JAAS, JGSS-API and SASL from 'security' module and create a
separate module for them (name for module?). The rest of 'security' to be
combined with 'crypto' module.
See
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c906dd82e0601182114v3af679f5n95a58fe4fb1355fc@mail.gmail.com%3e

3) Performance testing (status: the discussion got stuck, no decision was
made)
There is PerformanceTest super class that should be substituted with some
other mechanism. (JUnit decoration, simple Logger …)

4) Test framework (status: the discussion got stuck, no decision was made)
Where to place unit tests and how we are going to run 'security2' unit tests
(bootclass path vs. classpath)?


I'm going to update this list periodically. Please feel free to add any
other issues to this list.

Please let me know how I can help in these and other tasks.

Thanks,
Stepan Mishura
Intel Middleware Products Division

Re: 'security2' TODOs list

Posted by Stepan Mishura <st...@gmail.com>.
Status update




> 1) Moving com.openintel to org.apache.harmony (status: almost DONE)
> Issues:
> - Did we agree on com.openintel.drlx.* -> org.apache.harmony.x.*?
> - Tim had problems with running security tests.
>

Done

 2) Integrate build files (status: NONE)
> - split 'security2' to components
> - compiling native code
> - compile and run unit tests
>
In progress:
- A patch was provided for creating x_net component
(see http://issues.apache.org/jira/browse/HARMONY-48)


 Issues that may be resolved later:
>
> 1) Writing JavaDoc (status: the discussion got stuck, no decision was
> made)
> 'security2' has "com.intel.drl.spec_ref" javadoc tag that should be
> replaced
>

In progress


 2) New Modules or Components
> a. Providers: put providers into separate modules (status: no objections)
> See
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c6e47b64f0601170332k3d418fabwd25a264c5e0f1532@mail.gmail.com%3e
>

No objections

 b. Do reorg in security component: (status: no replies)
> Pick out JAAS, JGSS-API and SASL from 'security' module and create a
> separate module for them (name for module?). The rest of 'security' to be
> combined with 'crypto' module.
> See http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c906dd82e0601182114v3af679f5n95a58fe4fb1355fc@mail.gmail.com%3e
>
>

No progress since initial proposal
Well, I placed this item in not blocking list but I think that it would be
better to decide whether we are going to do reorganization or not before
continuing splitting 'security2' in components. So I'd like to attract
community attention to this proposal.


> 3) Performance testing (status: the discussion got stuck, no decision was
> made)
> There is PerformanceTest super class that should be substituted with some
> other mechanism. (JUnit decoration, simple Logger …)
>

In progress:
1) A patch was provided for removing redundant tests logging
(see http://issues.apache.org/jira/browse/HARMONY-44)
2) Discussing: performance testing, tests' logging, running tests in
different configurations


 4) Test framework (status: the discussion got stuck, no decision was made)
> Where to place unit tests and how we are going to run 'security2' unit
> tests (bootclass path vs. classpath)?
>
In progress

Thanks,
Stepan Mishura
Intel Middleware Products Division

Re: 'security2' TODOs list

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Geir Magnusson Jr wrote:
> 
> 
> Stepan Mishura wrote:
>>
>> 2) Integrate build files (status: NONE)
>> - split 'security2' to components
>> - compiling native code
>> - compile and run unit tests
> 
> I did integrate the build files.  You can kick of an "ant" from the top 
> and you get the whole thing.  There is one issue regarding where jni.h 
> comes from that George stumbled over, but I'll fix tha tnow.
>

Wait - I did a hack for windows - I need to do it right for Linux....

geir

Re: 'security2' TODOs list

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Stepan Mishura wrote:
> 
>  >>
>  >> I'd like to create a list of TODO's to track all issues related to
>  >> 'security2' module integration. Because it is hard to figure out from
>  >many
>  >> threads in mailing list what things were done, what blocks us to move
>  >> forward and what can be resolved later. Also this list should help us to
>  >> understand who took responsibility for a selected item and where we can
>  >> help. So here is the summary of issues:
>  >>
>  >> Issues that should be resolved before substituting the current 
> 'security'
>  >> module
>  >>
>  >> 1) Moving com.openintel to org.apache.harmony (status: almost DONE)
>  >> Issues:
>  >> - Did we agree on com.openintel.drlx.* -> org.apache.harmony.x.*?
>  >
>  >Either way, it's done.
> 
> Well, I don't remember that this variant was proposed and discussed: 
> com.openintel.drlx.* -> org.apache.harmony.security.x.*

Nope - I just did it because I was in the middle of moving it. You made 
a good argument that we needed to keep *.drlx.* in a separate package, 
so I did that.  I don't really care what it's called.

> 
> So now we have org.apache.harmony.security.x.security.auth package name 
> that looks quite strange for me.

You should have seen the *.fortress.* package name.

This comes down to organization, rather than aesthetics.  We are going 
to have org.apache.harmony.

I'd like to consider adding "classlib" in there to give a bit of future 
prooofing to o.a.h namespace.

I do think for sanity sake, we want to have something that gives a hint 
on the module, hence "org.apache.harmony.security" as it's in the 
security module.

> 
> Question: Is this a temporary naming pattern? I mean 
> org.apache.harmony.<element>.x.*, otherwise I'd expect to have the 
> following package names for support classes
> 1) javax.net <http://javax.net> -> org.apache.harmony.net.x.*
> 2) javax.rmi -> org.apache.harmony.rmi.x.*
> 3) javax.sql -> org.apache.harmony.sql.x.*
> 
> Are you OK with package names above?

Well, right now, we have modules that span the java[x].* packaging, and 
that is reflected in the namespace.  I'd like to keep that if we can.

> 
>  >
>  >> - Tim had problems with running security tests.
>  >
>  >Not sure - he didn't have the patience for one of them, and was startled
>  >by the amount of gibberish the tests spewed to stdout.
>  >
>  >Tim?
>  >
> 
> As I understood Tim needs ant target 'tests.run' that simply runs tests.

Yes - he was able to type "ant tests.run", but thought there was a 
problem due to the verbose output, and he thought one test hung it ran 
so long.  (KeyGen IIRC)

> 
>  >>
>  >> 2) Integrate build files (status: NONE)
>  >> - split 'security2' to components
>  >> - compiling native code
>  >> - compile and run unit tests
>  >
>  >I did integrate the build files.  You can kick of an "ant" from the top
>  >and you get the whole thing.  There is one issue regarding where jni.h
>  >comes from that George stumbled over, but I'll fix tha tnow.
>  >
> 
> May be it make sense, as Leo suggested, to fill JIRA tracker say: 
> "integrate security2 build". And we'll provide a patch or series of 
> patches (one for each issue) to enhance the current build with the 
> following:
> - building a number of separate components from 'security2'
> - compiling native code on Windows and Linux
> - add target for compiling unit tests
> - add target for running unit tests

Break these up into separate issues.  We already should have targets for 
the above.


> 
> The build modification is bounded with component reorg and discussion 
> about test framework. But IMHO they are not blocker issues and our 
> modifications may be adjusted later.

Yep

> 
>  >>
>  >> Issues that may be resolved later:
>  >>
>  >> 1) Writing JavaDoc (status: the discussion got stuck, no decision was
>  >made)
>  >> 'security2' has "com.intel.drl.spec_ref " javadoc tag that should be
>  >replaced
>  >
>  >That will be replaced, at least with our own for now as we evolve the
>  >javadoc discussion.
>  >
> 
> OK
> 
>  >>
>  >>
>  >> 2) New Modules or Components
>  >> a. Providers: put providers into separate modules (status: no 
> objections)
>  >> See
>  >> http://mail-archives.apache.org/mod_mbox/incubator-harmony-
>  >dev/200601.mbox/%3c6e47b64f0601170332k3d418fabwd25a264c5e0f1532@mail.gmail 
> <ma...@mail.gmail>.
>  >com%3e
>  >>
>  >> b. Do reorg in security component: (status: no replies)
>  >> Pick out JAAS, JGSS-API and SASL from 'security' module and create a
>  >> separate module for them (name for module?). The rest of 'security' 
> to be
>  >> combined with 'crypto' module.
>  >> See
>  >> http://mail-archives.apache.org/mod_mbox/incubator-harmony-
>  > 
> dev/200601.mbox/%3c906dd82e0601182114v3af679f5n95a58fe4fb1355fc@mail.gmail 
> <ma...@mail.gmail>.
>  >com%3e
>  >>
>  >
>  >Yep - that's a todo .
>  >
>  >> 3) Performance testing (status: the discussion got stuck, no 
> decision was
>  >> made)
>  >> There is PerformanceTest super class that should be substituted with 
> some
>  >> other mechanism. (JUnit decoration, simple Logger …)
>  >
>  >I think that there's general agreement we need another approach to this
>  >- it's too intrusive to have our test class hierarchy rooted in this...
>  >
> 
> Agree that we need another approach but IMO this is not a blocker issue.
> 
>  >>
>  >> 4) Test framework (status: the discussion got stuck, no decision was
>  >made)
>  >> Where to place unit tests and how we are going to run 'security2' unit
>  >tests
>  >> (bootclass path vs. classpath)?
>  >
>  >You keep saying "stuck", and I don't think that's right.  It's just in
>  >progress, IMO.  It's an interesting conversation.
>  >
> 
> Well, there are no new thoughts for a number of days and all sides keep 
> staying on their own opinions. So there is no progress and I'd like say 
> "stuck" :-)

Whatever.  I just haven't had time to continue.

> 
>  >>
>  >>
>  >> I'm going to update this list periodically. Please feel free to add any
>  >> other issues to this list.
>  >>
>  >> Please let me know how I can help in these and other tasks.
>  >
>  >Maybe think about how to get PerformanceTest moved elsewhere into
>  >another "performance testing framework"?
>  >
> 
> Mikhail said that PerformanceTest can be eliminated for now. I do not 
> see any remaining issue here.

Nope...  except for the logging...

geir


Re: 'security2' TODOs list

Posted by Stepan Mishura <st...@gmail.com>.
>>
>> I'd like to create a list of TODO's to track all issues related to
>> 'security2' module integration. Because it is hard to figure out from
>many
>> threads in mailing list what things were done, what blocks us to move
>> forward and what can be resolved later. Also this list should help us to
>> understand who took responsibility for a selected item and where we can
>> help. So here is the summary of issues:
>>
>> Issues that should be resolved before substituting the current 'security'
>> module
>>
>> 1) Moving com.openintel to org.apache.harmony (status: almost DONE)
>> Issues:
>> - Did we agree on com.openintel.drlx.* -> org.apache.harmony.x.*?
>
>Either way, it's done.

Well, I don't remember that this variant was proposed and discussed:
com.openintel.drlx.* -> org.apache.harmony.security.x.*

So now we have org.apache.harmony.security.x.security.auth package name that
looks quite strange for me.

Question: Is this a temporary naming pattern? I mean
org.apache.harmony.<element>.x.*,
otherwise I'd expect to have the following package names for support classes
1) javax.net -> org.apache.harmony.net.x.*
2) javax.rmi -> org.apache.harmony.rmi.x.*
3) javax.sql -> org.apache.harmony.sql.x.*

Are you OK with package names above?

>
>> - Tim had problems with running security tests.
>
>Not sure - he didn't have the patience for one of them, and was startled
>by the amount of gibberish the tests spewed to stdout.
>
>Tim?
>

As I understood Tim needs ant target 'tests.run' that simply runs tests.

>>
>> 2) Integrate build files (status: NONE)
>> - split 'security2' to components
>> - compiling native code
>> - compile and run unit tests
>
>I did integrate the build files.  You can kick of an "ant" from the top
>and you get the whole thing.  There is one issue regarding where jni.h
>comes from that George stumbled over, but I'll fix tha tnow.
>

May be it make sense, as Leo suggested, to fill JIRA tracker say: "integrate
security2 build". And we'll provide a patch or series of patches (one for
each issue) to enhance the current build with the following:
- building a number of separate components from 'security2'
- compiling native code on Windows and Linux
- add target for compiling unit tests
- add target for running unit tests

The build modification is bounded with component reorg and discussion about
test framework. But IMHO they are not blocker issues and our modifications
may be adjusted later.

>>
>> Issues that may be resolved later:
>>
>> 1) Writing JavaDoc (status: the discussion got stuck, no decision was
>made)
>> 'security2' has "com.intel.drl.spec_ref" javadoc tag that should be
>replaced
>
>That will be replaced, at least with our own for now as we evolve the
>javadoc discussion.
>

OK

>>
>>
>> 2) New Modules or Components
>> a. Providers: put providers into separate modules (status: no objections)
>> See
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-
>dev/200601.mbox/%3c6e47b64f0601170332k3d418fabwd25a264c5e0f1532@mail.gmail.
>com%3e
>>
>> b. Do reorg in security component: (status: no replies)
>> Pick out JAAS, JGSS-API and SASL from 'security' module and create a
>> separate module for them (name for module?). The rest of 'security' to be
>> combined with 'crypto' module.
>> See
>> http://mail-archives.apache.org/mod_mbox/incubator-harmony-
>dev/200601.mbox/%3c906dd82e0601182114v3af679f5n95a58fe4fb1355fc@mail.gmail.
>com%3e
>>
>
>Yep - that's a todo .
>
>> 3) Performance testing (status: the discussion got stuck, no decision was
>> made)
>> There is PerformanceTest super class that should be substituted with some
>> other mechanism. (JUnit decoration, simple Logger …)
>
>I think that there's general agreement we need another approach to this
>- it's too intrusive to have our test class hierarchy rooted in this...
>

Agree that we need another approach but IMO this is not a blocker issue.

>>
>> 4) Test framework (status: the discussion got stuck, no decision was
>made)
>> Where to place unit tests and how we are going to run 'security2' unit
>tests
>> (bootclass path vs. classpath)?
>
>You keep saying "stuck", and I don't think that's right.  It's just in
>progress, IMO.  It's an interesting conversation.
>

Well, there are no new thoughts for a number of days and all sides keep
staying on their own opinions. So there is no progress and I'd like say
"stuck" :-)

>>
>>
>> I'm going to update this list periodically. Please feel free to add any
>> other issues to this list.
>>
>> Please let me know how I can help in these and other tasks.
>
>Maybe think about how to get PerformanceTest moved elsewhere into
>another "performance testing framework"?
>

Mikhail said that PerformanceTest can be eliminated for now. I do not see
any remaining issue here.

Thanks,
Stepan Mishura
Intel Middleware Products Division


On 1/23/06, Geir Magnusson Jr <ge...@pobox.com> wrote:
>
>
>
> Stepan Mishura wrote:
> > Hello,
> >
> > I'd like to create a list of TODO's to track all issues related to
> > 'security2' module integration. Because it is hard to figure out from
> many
> > threads in mailing list what things were done, what blocks us to move
> > forward and what can be resolved later. Also this list should help us to
> > understand who took responsibility for a selected item and where we can
> > help. So here is the summary of issues:
> >
> > Issues that should be resolved before substituting the current
> 'security'
> > module
> >
> > 1) Moving com.openintel to org.apache.harmony (status: almost DONE)
> > Issues:
> > - Did we agree on com.openintel.drlx.* -> org.apache.harmony.x.*?
>
> Either way, it's done.
>
> > - Tim had problems with running security tests.
>
> Not sure - he didn't have the patience for one of them, and was startled
> by the amount of gibberish the tests spewed to stdout.
>
> Tim?
>
> >
> > 2) Integrate build files (status: NONE)
> > - split 'security2' to components
> > - compiling native code
> > - compile and run unit tests
>
> I did integrate the build files.  You can kick of an "ant" from the top
> and you get the whole thing.  There is one issue regarding where jni.h
> comes from that George stumbled over, but I'll fix tha tnow.
>
> >
> > Issues that may be resolved later:
> >
> > 1) Writing JavaDoc (status: the discussion got stuck, no decision was
> made)
> > 'security2' has "com.intel.drl.spec_ref" javadoc tag that should be
> replaced
>
> That will be replaced, at least with our own for now as we evolve the
> javadoc discussion.
>
> >
> >
> > 2) New Modules or Components
> > a. Providers: put providers into separate modules (status: no
> objections)
> > See
> >
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c6e47b64f0601170332k3d418fabwd25a264c5e0f1532@mail.gmail.com%3e
> >
> > b. Do reorg in security component: (status: no replies)
> > Pick out JAAS, JGSS-API and SASL from 'security' module and create a
> > separate module for them (name for module?). The rest of 'security' to
> be
> > combined with 'crypto' module.
> > See
> >
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c906dd82e0601182114v3af679f5n95a58fe4fb1355fc@mail.gmail.com%3e
> >
>
> Yep - that's a todo .
>
> > 3) Performance testing (status: the discussion got stuck, no decision
> was
> > made)
> > There is PerformanceTest super class that should be substituted with
> some
> > other mechanism. (JUnit decoration, simple Logger …)
>
> I think that there's general agreement we need another approach to this
> - it's too intrusive to have our test class hierarchy rooted in this...
>
> >
> > 4) Test framework (status: the discussion got stuck, no decision was
> made)
> > Where to place unit tests and how we are going to run 'security2' unit
> tests
> > (bootclass path vs. classpath)?
>
> You keep saying "stuck", and I don't think that's right.  It's just in
> progress, IMO.  It's an interesting conversation.
>
> >
> >
> > I'm going to update this list periodically. Please feel free to add any
> > other issues to this list.
> >
> > Please let me know how I can help in these and other tasks.
>
> Maybe think about how to get PerformanceTest moved elsewhere into
> another "performance testing framework"?
>
> geir
>
> >
> > Thanks,
> > Stepan Mishura
> > Intel Middleware Products Division
>



--
Thanks,
Stepan Mishura
Intel Middleware Products Division

Re: 'security2' TODOs list

Posted by Geir Magnusson Jr <ge...@pobox.com>.

Stepan Mishura wrote:
> Hello,
> 
> I'd like to create a list of TODO's to track all issues related to
> 'security2' module integration. Because it is hard to figure out from many
> threads in mailing list what things were done, what blocks us to move
> forward and what can be resolved later. Also this list should help us to
> understand who took responsibility for a selected item and where we can
> help. So here is the summary of issues:
> 
> Issues that should be resolved before substituting the current 'security'
> module
> 
> 1) Moving com.openintel to org.apache.harmony (status: almost DONE)
> Issues:
> - Did we agree on com.openintel.drlx.* -> org.apache.harmony.x.*?

Either way, it's done.

> - Tim had problems with running security tests.

Not sure - he didn't have the patience for one of them, and was startled 
by the amount of gibberish the tests spewed to stdout.

Tim?

> 
> 2) Integrate build files (status: NONE)
> - split 'security2' to components
> - compiling native code
> - compile and run unit tests

I did integrate the build files.  You can kick of an "ant" from the top 
and you get the whole thing.  There is one issue regarding where jni.h 
comes from that George stumbled over, but I'll fix tha tnow.

> 
> Issues that may be resolved later:
> 
> 1) Writing JavaDoc (status: the discussion got stuck, no decision was made)
> 'security2' has "com.intel.drl.spec_ref" javadoc tag that should be replaced

That will be replaced, at least with our own for now as we evolve the 
javadoc discussion.

> 
> 
> 2) New Modules or Components
> a. Providers: put providers into separate modules (status: no objections)
> See
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c6e47b64f0601170332k3d418fabwd25a264c5e0f1532@mail.gmail.com%3e
> 
> b. Do reorg in security component: (status: no replies)
> Pick out JAAS, JGSS-API and SASL from 'security' module and create a
> separate module for them (name for module?). The rest of 'security' to be
> combined with 'crypto' module.
> See
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c906dd82e0601182114v3af679f5n95a58fe4fb1355fc@mail.gmail.com%3e
> 

Yep - that's a todo .

> 3) Performance testing (status: the discussion got stuck, no decision was
> made)
> There is PerformanceTest super class that should be substituted with some
> other mechanism. (JUnit decoration, simple Logger …)

I think that there's general agreement we need another approach to this 
- it's too intrusive to have our test class hierarchy rooted in this...

> 
> 4) Test framework (status: the discussion got stuck, no decision was made)
> Where to place unit tests and how we are going to run 'security2' unit tests
> (bootclass path vs. classpath)?

You keep saying "stuck", and I don't think that's right.  It's just in 
progress, IMO.  It's an interesting conversation.

> 
> 
> I'm going to update this list periodically. Please feel free to add any
> other issues to this list.
> 
> Please let me know how I can help in these and other tasks.

Maybe think about how to get PerformanceTest moved elsewhere into 
another "performance testing framework"?

geir

> 
> Thanks,
> Stepan Mishura
> Intel Middleware Products Division

Re: 'security2' TODOs list

Posted by Leo Simons <ma...@leosimons.com>.
On Mon, Jan 23, 2006 at 05:07:05PM +0600, Stepan Mishura wrote:
> I'm going to update this list periodically. Please feel free to add any
> other issues to this list.
> 
> Please let me know how I can help in these and other tasks.

I'd suggest using jira for TODO tracking :-)

LSD


Re: 'security2' TODOs list

Posted by Stepan Mishura <st...@gmail.com>.
Status update


> 1) Moving com.openintel to org.apache.harmony (status: almost DONE)
> Issues:
> - Did we agree on com.openintel.drlx.* -> org.apache.harmony.x.*?
> - Tim had problems with running security tests.
>

Done

 2) Integrate build files (status: NONE)
> - split 'security2' to components
> - compiling native code
> - compile and run unit tests
>

In progress:
- A patch was provided for creating x_net component
(see http://issues.apache.org/jira/browse/HARMONY-48)
- A patch was provided for running security2 tests on Harmony codebase
(see http://issues.apache.org/jira/browse/HARMONY-58)

Done:
- Experimented with contribution of java.math library: most of tests
failures caused by stub implementation will be resolved.

 Issues that may be resolved later:
>
> 1) Writing JavaDoc (status: the discussion got stuck, no decision was
> made)
> 'security2' has "com.intel.drl.spec_ref" javadoc tag that should be
> replaced
>

In progress:
- Did everybody agree on that Harmony javadoc will contain a link to the
J2SE specification?

 2) New Modules or Components
> a. Providers: put providers into separate modules (status: no objections)
> See
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c6e47b64f0601170332k3d418fabwd25a264c5e0f1532@mail.gmail.com%3e
>

No objections

 b. Do reorg in security component: (status: no replies)
> Pick out JAAS, JGSS-API and SASL from 'security' module and create a
> separate module for them (name for module?). The rest of 'security' to be
> combined with 'crypto' module.
> See http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/%3c906dd82e0601182114v3af679f5n95a58fe4fb1355fc@mail.gmail.com%3e
>
>

In progress
- No objections, a suggested name for a new component is 'security-x'

 3) Performance testing (status: the discussion got stuck, no decision was
> made)
> There is PerformanceTest super class that should be substituted with some
> other mechanism. (JUnit decoration, simple Logger …)
>


In progress:
- Discussing: running tests in different configurations

Done:
- A patch was applied for removing redundant tests logging
(see http://issues.apache.org/jira/browse/HARMONY-44)
- A patch was applied for removing PerformanceTest super class
(see http://issues.apache.org/jira/browse/HARMONY-55)

 4) Test framework (status: the discussion got stuck, no decision was made)
> Where to place unit tests and how we are going to run 'security2' unit
> tests (bootclass path vs. classpath)?
>
In progress

Thanks,
Stepan Mishura
Intel Middleware Products Division