RE: Writing JavaDoc (was: Re: [RESULT] ( Was Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)))
inline > -Original Message- > From: Tim Ellison [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 10, 2006 5:26 AM > To: harmony-dev@incubator.apache.org > Subject: Writing JavaDoc (was: Re: [RESULT] ( Was Re: [VOTE] > Accept JIRA contribution HARMONY-16 (Intel's contrib of > security code for classlib))) > > Loenko, Mikhail Y wrote: > > Thanks for accepting the contribution > > > > > >>There's a bit of things that come out of this, like the > >>"com.intel.drl.spec_ref" javadoc tag that we should > convert, and such. > > > > > > What would be the best for those javadocs? We can have 3 possible > > options: > > 1. Copy-paste from the spec. Not sure it is legal > > This one definitely has to be out. The Sun JavaDoc is a > copyrighted/licensed work so making a verbatim copy is unacceptable. > > > 2. Reword the spec. More likely to be legal > > As I see it, the JavaDoc fulfils (at least) two purposes. It embodies > the java spec (i.e. the definition of the standard library's > behaviour), > and it is the principal developer documentation (i.e. how to use the > library). We do not want to change the specification in any way, but > can enhance the usability of the documentation to developers. > > For example, it would IMHO be wrong to specify the behaviour > of a method > with more/less restrictions than the original reference > javadoc, because > that implies that developers can make assumptions on one > implementation > that they cannot on the other. However, it is reasonable to give more > examples, usecases, even performance, threading guidelines, > etc. that do > not change the functional specification. Yes - augmenting the spec with information about our implementation. > > So I'd say writing some JavaDoc, that was neither a direct copy of the > original, nor 'enhancing' the specification, can provide value to > developers. But I think that we need to be clear, pointing to the Sun javadoc as the specificatoin for J2SE, like it or not. If not, we ensure that we work on the next rev of J2SE to fix the javadoc. However, we should certainly augment. > > > 3. Replace the tag with a different one and provide taglet > to build the > > doc from the Harmony sources and Sun's spec. > > If I understand this correctly, then I don't see how this is > substantially different to option (1)? Whether it is a human > that does > the cut-n-paste into the Harmony release, or a doclet, the result > includes somebody else's work. Right - we don't copy Sun's JavaDoc content. For java.*, I think that we can have a a "implementation notes javadoc" if we need to, and of course javadoc our implementation well? Geir -- Geir Magnusson Jr [EMAIL PROTECTED] SSG/MPD +1 203 665 6437
RE: [RESULT] ( Was Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib))
inline -- Geir Magnusson Jr [EMAIL PROTECTED] SSG/MPD +1 203 665 6437 > -Original Message- > From: Loenko, Mikhail Y [mailto:[EMAIL PROTECTED] > Sent: Tuesday, January 10, 2006 3:53 AM > To: harmony-dev@incubator.apache.org > Subject: RE: [RESULT] ( Was Re: [VOTE] Accept JIRA > contribution HARMONY-16 (Intel's contrib of security code for > classlib)) > > Thanks for accepting the contribution > > >There's a bit of things that come out of this, like the > >"com.intel.drl.spec_ref" javadoc tag that we should convert, > and such. > > What would be the best for those javadocs? We can have 3 possible > options: > 1. Copy-paste from the spec. Not sure it is legal Absolutely not. The legality is actually open to honest and genuine debate - fair use and such - but it's an active issue w/ the EC and something I'd rather see come to conclusion before "poking the bear". > 2. Reword the spec. More likely to be legal 100% legit > 3. Replace the tag with a different one and provide taglet to > build the > doc from the Harmony sources and Sun's spec. I think we just point to Sun's spec. > > Currently IBM's contribution seems to have #2. Does anyone have an > opinion? > > Thanks, > Mikhail Loenko > Intel Middleware Products Division > > >-Original Message- > >From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] > >Sent: Friday, December 30, 2005 10:48 PM > >To: harmony-dev@incubator.apache.org > >Subject: Re: [RESULT] ( Was Re: [VOTE] Accept JIRA contribution > HARMONY-16 (Intel's contrib of > >security code for classlib)) > > > > > > > >Tim Ellison wrote: > >> Geir Magnusson Jr. wrote: > >> > >> > >>>I'll finish moving to SVN and we'll put into the classlib tree, I > suppose. > >> > >> > >> Great. Thanks again Mikhail and the team! > >> > >> I suggest you either put it into the classlib tree at > >> "classlib/java-src/security2" or leave it in the sandbox, > then we can > >> merge it into the existing security structure without breaking the > world. > > > >I'll go for the former and try to whip it into common shape, > and we can > >then decide how we do this - drop the existing security if > security2 is > >a superset, or merge. > > > >There's a bit of things that come out of this, like the > >"com.intel.drl.spec_ref" javadoc tag that we should convert, > and such. > > > >Also will give me a good change to frame out the test infra. > > > > > >> > >> Regards, > >> Tim > >> >
Writing JavaDoc (was: Re: [RESULT] ( Was Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)))
Loenko, Mikhail Y wrote: > Thanks for accepting the contribution > > >>There's a bit of things that come out of this, like the >>"com.intel.drl.spec_ref" javadoc tag that we should convert, and such. > > > What would be the best for those javadocs? We can have 3 possible > options: > 1. Copy-paste from the spec. Not sure it is legal This one definitely has to be out. The Sun JavaDoc is a copyrighted/licensed work so making a verbatim copy is unacceptable. > 2. Reword the spec. More likely to be legal As I see it, the JavaDoc fulfils (at least) two purposes. It embodies the java spec (i.e. the definition of the standard library's behaviour), and it is the principal developer documentation (i.e. how to use the library). We do not want to change the specification in any way, but can enhance the usability of the documentation to developers. For example, it would IMHO be wrong to specify the behaviour of a method with more/less restrictions than the original reference javadoc, because that implies that developers can make assumptions on one implementation that they cannot on the other. However, it is reasonable to give more examples, usecases, even performance, threading guidelines, etc. that do not change the functional specification. So I'd say writing some JavaDoc, that was neither a direct copy of the original, nor 'enhancing' the specification, can provide value to developers. > 3. Replace the tag with a different one and provide taglet to build the > doc from the Harmony sources and Sun's spec. If I understand this correctly, then I don't see how this is substantially different to option (1)? Whether it is a human that does the cut-n-paste into the Harmony release, or a doclet, the result includes somebody else's work. Regards, Tim > Currently IBM's contribution seems to have #2. Does anyone have an > opinion? > > Thanks, > Mikhail Loenko > Intel Middleware Products Division > > >>-Original Message- >>From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >>Sent: Friday, December 30, 2005 10:48 PM >>To: harmony-dev@incubator.apache.org >>Subject: Re: [RESULT] ( Was Re: [VOTE] Accept JIRA contribution > > HARMONY-16 (Intel's contrib of > >>security code for classlib)) >> >> >> >>Tim Ellison wrote: >> >>>Geir Magnusson Jr. wrote: >>> >>> >>>>I'll finish moving to SVN and we'll put into the classlib tree, I > > suppose. > >>> >>>Great. Thanks again Mikhail and the team! >>> >>>I suggest you either put it into the classlib tree at >>>"classlib/java-src/security2" or leave it in the sandbox, then we can >>>merge it into the existing security structure without breaking the > > world. > >>I'll go for the former and try to whip it into common shape, and we can >>then decide how we do this - drop the existing security if security2 is >>a superset, or merge. >> >>There's a bit of things that come out of this, like the >>"com.intel.drl.spec_ref" javadoc tag that we should convert, and such. >> >>Also will give me a good change to frame out the test infra. >> >> >> >>>Regards, >>>Tim >>> > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
RE: [RESULT] ( Was Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib))
Thanks for accepting the contribution >There's a bit of things that come out of this, like the >"com.intel.drl.spec_ref" javadoc tag that we should convert, and such. What would be the best for those javadocs? We can have 3 possible options: 1. Copy-paste from the spec. Not sure it is legal 2. Reword the spec. More likely to be legal 3. Replace the tag with a different one and provide taglet to build the doc from the Harmony sources and Sun's spec. Currently IBM's contribution seems to have #2. Does anyone have an opinion? Thanks, Mikhail Loenko Intel Middleware Products Division >-Original Message- >From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED] >Sent: Friday, December 30, 2005 10:48 PM >To: harmony-dev@incubator.apache.org >Subject: Re: [RESULT] ( Was Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of >security code for classlib)) > > > >Tim Ellison wrote: >> Geir Magnusson Jr. wrote: >> >> >>>I'll finish moving to SVN and we'll put into the classlib tree, I suppose. >> >> >> Great. Thanks again Mikhail and the team! >> >> I suggest you either put it into the classlib tree at >> "classlib/java-src/security2" or leave it in the sandbox, then we can >> merge it into the existing security structure without breaking the world. > >I'll go for the former and try to whip it into common shape, and we can >then decide how we do this - drop the existing security if security2 is >a superset, or merge. > >There's a bit of things that come out of this, like the >"com.intel.drl.spec_ref" javadoc tag that we should convert, and such. > >Also will give me a good change to frame out the test infra. > > >> >> Regards, >> Tim >>
Re: [RESULT] ( Was Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib))
Tim Ellison wrote: Geir Magnusson Jr. wrote: I'll finish moving to SVN and we'll put into the classlib tree, I suppose. Great. Thanks again Mikhail and the team! I suggest you either put it into the classlib tree at "classlib/java-src/security2" or leave it in the sandbox, then we can merge it into the existing security structure without breaking the world. I'll go for the former and try to whip it into common shape, and we can then decide how we do this - drop the existing security if security2 is a superset, or merge. There's a bit of things that come out of this, like the "com.intel.drl.spec_ref" javadoc tag that we should convert, and such. Also will give me a good change to frame out the test infra. Regards, Tim
Re: [RESULT] ( Was Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib))
Geir Magnusson Jr. wrote: > I'll finish moving to SVN and we'll put into the classlib tree, I suppose. Great. Thanks again Mikhail and the team! I suggest you either put it into the classlib tree at "classlib/java-src/security2" or leave it in the sandbox, then we can merge it into the existing security structure without breaking the world. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[RESULT] ( Was Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib))
I let this run long because Leo might have found some time... +1 : geir, dims, tim, david, stefano, (w/ nonbinding support from enrico, jaime, ashish) 0 : leo No one against. BTW, anyone and everyone can offer their support/opinion even if non- binding. I would be good to see the contributor also show their support ;) I'll finish moving to SVN and we'll put into the classlib tree, I suppose. geir On Dec 20, 2005, at 6:55 PM, Geir Magnusson Jr. wrote: Intel has offered an addition to the classlib effort in the form of security code to the project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-16 The paperwork (Bulk Contribution Checklist and supporting documentation) has been received and all documentation is in place. Therefore : [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. (+1 from me, of course...) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)
Hi Geir, If intel is offering this in apache license with docs, then nothing better than that for Apache Harmony security code. +1 from me too. useful addition. bye :-) Ashish Ranjan [EMAIL PROTECTED] [EMAIL PROTECTED] On 12/21/05, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote: > > Geir Magnusson Jr. wrote: > > > > Intel has offered an addition to the classlib effort in the form of > > security code to the project under the Apache License to Apache > > Harmony. It can be found here : > > > > http://issues.apache.org/jira/browse/HARMONY-16 > > > > The paperwork (Bulk Contribution Checklist and supporting documentation) > > has been received and all documentation is in place. > > > > Therefore : > > > > [ ] +1 Accept the code into the project sandbox > > [ ] -1 Don't accept the code. Reason : > > > > This vote will close 72 hours from now. > > > > (+1 from me, of course...) > > +1 > > -- > Stefano. > >
Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)
Geir Magnusson Jr. wrote: Intel has offered an addition to the classlib effort in the form of security code to the project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-16 The paperwork (Bulk Contribution Checklist and supporting documentation) has been received and all documentation is in place. Therefore : [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. (+1 from me, of course...) +1 -- Stefano.
RE: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)
+1 -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 20, 2005 6:56 PM To: harmony-dev@incubator.apache.org Subject: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib) Intel has offered an addition to the classlib effort in the form of security code to the project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-16 The paperwork (Bulk Contribution Checklist and supporting documentation) has been received and all documentation is in place. Therefore : [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. (+1 from me, of course...) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)
+1 (non-binding), thanks Intel! David. On Tue, 2005-12-20 at 18:55 -0500, Geir Magnusson Jr. wrote: > Intel has offered an addition to the classlib effort in the form of > security code to the project under the Apache License to Apache > Harmony. It can be found here : > > http://issues.apache.org/jira/browse/HARMONY-16 > > The paperwork (Bulk Contribution Checklist and supporting > documentation) has been received and all documentation is in place. > > Therefore : > > [ ] +1 Accept the code into the project sandbox > [ ] -1 Don't accept the code. Reason : > > This vote will close 72 hours from now. > > (+1 from me, of course...) > > geir > -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- METHODEN DER BEWEISFHRUNG -- WISCHWEG - METHODE Man wischt die entscheidenden Stellen des Beweises sofort nach dem Anschreiben wieder weg (rechts schreiben, links wischen). smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)
+1 Geir Magnusson Jr. wrote: > > Intel has offered an addition to the classlib effort in the form of > security code to the project under the Apache License to Apache > Harmony. It can be found here : > > http://issues.apache.org/jira/browse/HARMONY-16 > > The paperwork (Bulk Contribution Checklist and supporting > documentation) has been received and all documentation is in place. > > Therefore : > > [ ] +1 Accept the code into the project sandbox > [ ] -1 Don't accept the code. Reason : > > This vote will close 72 hours from now. > > (+1 from me, of course...) > > geir > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)
+1 Enrico Intel has offered an addition to the classlib effort in the form of security code to the project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-16 The paperwork (Bulk Contribution Checklist and supporting documentation) has been received and all documentation is in place. Therefore : [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. (+1 from me, of course...) geir
Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)
Leo, the code has been there for weeks at this point -Original Message- From: Leo Simons [mailto:[EMAIL PROTECTED] Sent: Tue Dec 20 17:48:38 2005 To: harmony-dev@incubator.apache.org Subject:Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib) I'm not going to have time for review within the next 7 day window I think. So +/-0 from me. Again the comment on 72 hours potentially being short... - LSD On Tue, Dec 20, 2005 at 06:55:44PM -0500, Geir Magnusson Jr. wrote: > > Intel has offered an addition to the classlib effort in the form of > security code to the project under the Apache License to Apache > Harmony. It can be found here : > > http://issues.apache.org/jira/browse/HARMONY-16 > > The paperwork (Bulk Contribution Checklist and supporting > documentation) has been received and all documentation is in place. > > Therefore : > > [ ] +1 Accept the code into the project sandbox > [ ] -1 Don't accept the code. Reason : > > This vote will close 72 hours from now. > > (+1 from me, of course...) > > geir > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] >
Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)
I'm not going to have time for review within the next 7 day window I think. So +/-0 from me. Again the comment on 72 hours potentially being short... - LSD On Tue, Dec 20, 2005 at 06:55:44PM -0500, Geir Magnusson Jr. wrote: > > Intel has offered an addition to the classlib effort in the form of > security code to the project under the Apache License to Apache > Harmony. It can be found here : > > http://issues.apache.org/jira/browse/HARMONY-16 > > The paperwork (Bulk Contribution Checklist and supporting > documentation) has been received and all documentation is in place. > > Therefore : > > [ ] +1 Accept the code into the project sandbox > [ ] -1 Don't accept the code. Reason : > > This vote will close 72 hours from now. > > (+1 from me, of course...) > > geir > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] >
Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)
+1 from me. On 12/20/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > Intel has offered an addition to the classlib effort in the form of > security code to the project under the Apache License to Apache > Harmony. It can be found here : > > http://issues.apache.org/jira/browse/HARMONY-16 > > The paperwork (Bulk Contribution Checklist and supporting > documentation) has been received and all documentation is in place. > > Therefore : > > [ ] +1 Accept the code into the project sandbox > [ ] -1 Don't accept the code. Reason : > > This vote will close 72 hours from now. > > (+1 from me, of course...) > > geir > > -- > Geir Magnusson Jr +1-203-665-6437 > [EMAIL PROTECTED] > > > -- Davanum Srinivas : http://wso2.com/blogs/
[VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)
Intel has offered an addition to the classlib effort in the form of security code to the project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-16 The paperwork (Bulk Contribution Checklist and supporting documentation) has been received and all documentation is in place. Therefore : [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. (+1 from me, of course...) geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
