harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: 'security2' TODOs list
Date Tue, 24 Jan 2006 12:56:31 GMT


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 
> <mailto: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 
> <mailto: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" :-)

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


Mime
View raw message