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/[EMAIL PROTECTED]
<mailto:dev/200601.mbox/[EMAIL PROTECTED]>.
>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/[EMAIL PROTECTED]
<mailto:dev/200601.mbox/[EMAIL PROTECTED]>.
>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
