Thread: Re: [Mockobjects-java-dev] [Proposal] List of tasks for release 0.02

Status: Beta

Brought to you by: custommonkey, macta, smgf, vmassol

mockobjects-java-dev

Re: [Mockobjects-java-dev] [Proposal] List of tasks for release 0.02

From: Tim M. <tim...@po...> - 2001-08-17 12:25:53

T7 is a task we need to make sure is treated properly! I dont believe in 
java doc - its an excuse to write bad code or a way of creating work for 
yourself (it is useful however if there is no source with your project 
but this doesnt affect us...) The better fix is to name things paoperly 
om to write better tests. Can this task just be to identify which 
classes need javadoc? My claim is that with T1-4 we shouldnt need any.

tim

Vincent Massol wrote:

> From: "Vincent Massol" <vm...@oc...>
> To: <moc...@li...>
> Subject: [Mockobjects-java-dev] [Proposal] List of tasks for release 0.02
> Date: Wed, 15 Aug 2001 15:14:15 +0100
> 
> Here is a list of tasks that I propose for Release 0.02. Can you please
> state your agreement and others that would like to see. I'll wait for your
> approval before entering them in the todo page :
> 
> T1 - [doc] What are MockObjects?
> T2 - [doc] Difference between MO and Stubs ?
> T3 - [doc] Goal page that explains short term and long term goals of the
> project
> T4 - [doc] Coding conventions (in a "Developer" menu)
> T5 - [doc] Features page
> T6 - [doc] Release process page (in a "Developer" menu)
> T7 - [code] add javadoc to all code where needed + add version number to
> sources (@version @version@) + packages.html + overview.html
> T8 - [code] Code aligned with coding conventions (and MO naming conventions
> already present on the web site)
> T9 - [build] finalized build process (still need to finalize directory
> structure + manage examples + manage extensions)
> 
> These are the "mnimum" set of task that is can we before the release 0.02.
> 
> Tell me also if you wish to volunteer for a given task. There can be several
> persons volunteering for the same task.
> 
> I volunteer for T2, T4, T6, T9.
> 
> Thanks
> -Vincent
> 
> 
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> 
>

Re: [Mockobjects-java-dev] [Proposal] List of tasks for release 0.02

From: Vincent M. <vm...@oc...> - 2001-08-17 15:14:50

I will divide T7 in several steps to make it more clear :

T7A - add javadoc to all code *where needed* (I put "where needed"
especially for Steve and Tim).
T7B - add version number to sources (@version @version@)
T7C - add packages.html to each package
T7D - add overview.html

Do we agee on that ? To answer Tim and Steve, I think T7C and T7D are more
important than T7A and are absolutely needed. Also do remember that a lot of
persons look at the javadoc but *not* at the source code (they just have the
runtime jar and go to the web site to look at the javadoc usually).

-Vincent

----- Original Message -----
From: "Tim Mackinnon" <tim...@po...>
To: <moc...@li...>;
<moc...@li...>
Sent: Thursday, August 16, 2001 11:32 AM
Subject: Re: [Mockobjects-java-dev] [Proposal] List of tasks for release
0.02


> T7 is a task we need to make sure is treated properly! I dont believe in
> java doc - its an excuse to write bad code or a way of creating work for
> yourself (it is useful however if there is no source with your project
> but this doesnt affect us...) The better fix is to name things paoperly
> om to write better tests. Can this task just be to identify which
> classes need javadoc? My claim is that with T1-4 we shouldnt need any.
>
> tim
>
> Vincent Massol wrote:
>
> > From: "Vincent Massol" <vm...@oc...>
> > To: <moc...@li...>
> > Subject: [Mockobjects-java-dev] [Proposal] List of tasks for release
0.02
> > Date: Wed, 15 Aug 2001 15:14:15 +0100
> >
> > Here is a list of tasks that I propose for Release 0.02. Can you please
> > state your agreement and others that would like to see. I'll wait for
your
> > approval before entering them in the todo page :
> >
> > T1 - [doc] What are MockObjects?
> > T2 - [doc] Difference between MO and Stubs ?
> > T3 - [doc] Goal page that explains short term and long term goals of the
> > project
> > T4 - [doc] Coding conventions (in a "Developer" menu)
> > T5 - [doc] Features page
> > T6 - [doc] Release process page (in a "Developer" menu)
> > T7 - [code] add javadoc to all code where needed + add version number to
> > sources (@version @version@) + packages.html + overview.html
> > T8 - [code] Code aligned with coding conventions (and MO naming
conventions
> > already present on the web site)
> > T9 - [build] finalized build process (still need to finalize directory
> > structure + manage examples + manage extensions)
> >
> > These are the "mnimum" set of task that is can we before the release
0.02.
> >
> > Tell me also if you wish to volunteer for a given task. There can be
several
> > persons volunteering for the same task.
> >
> > I volunteer for T2, T4, T6, T9.
> >
> > Thanks
> > -Vincent
> >
> >
> > _______________________________________________
> > Mockobjects-java-users mailing list
> > Moc...@li...
> > http://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> >
> >
>
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>

Re: [Mockobjects-java-dev] [Proposal] List of tasks for release 0.02

From: Steve F. <st...@m3...> - 2001-08-22 22:15:50

PiBUN0MgLSBhZGQgcGFja2FnZXMuaHRtbCB0byBlYWNoIHBhY2thZ2UNCj4gVDdEIC0gYWRkIG92
ZXJ2aWV3Lmh0bWwNCg0Kd2hhdCBnb2VzIGluIHRoZXNlPw0KDQpTdGV2ZQ0KDQo=

Re: [Mockobjects-java-dev] [Proposal] List of tasks for release 0.02

From: Vincent M. <vm...@oc...> - 2001-08-23 06:36:21

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 22, 2001 11:16 PM
Subject: Re: [Mockobjects-java-dev] [Proposal] List of tasks for release
0.02


> > T7C - add packages.html to each package

description of what a package is. This file will be picked up during javadoc
generation. (one per package)

> > T7D - add overview.html

same but for the first overview page of the javadoc (one in total)

>
> what goes in these?
>
> Steve
>
> 2?¡¸rÛjözùSX,X´Ê'?yË«uëSË²<qç®zØ¶Y-+²ÊÇ¢¸ë-+³ù²Ø~¡Én7¶È½§

Have a look at todo.xml, I have committed the task list yesterday.

P.S.: I really like your signature ... :-)

Re: [Mockobjects-java-dev] [Proposal] List of tasks for release 0.02

From: Vincent M. <vm...@oc...> - 2001-08-17 15:45:49

Tim, how often do you look at the JDK source code when you need to
understand how the BufferedReader.readLine() methods works and what it
returns if there is no more data to be read from the stream ?

Personnally I don't (although it is available, I even have it on my machine)
and I prefer to look at the javadoc !

Want to make a bet on how people do it ? :-)
Cheers,
-Vincent

----- Original Message -----
From: "Tim Mackinnon" <tim...@po...>
To: <moc...@li...>;
<moc...@li...>
Sent: Thursday, August 16, 2001 11:32 AM
Subject: Re: [Mockobjects-java-dev] [Proposal] List of tasks for release
0.02


> T7 is a task we need to make sure is treated properly! I dont believe in
> java doc - its an excuse to write bad code or a way of creating work for
> yourself (it is useful however if there is no source with your project
> but this doesnt affect us...) The better fix is to name things paoperly
> om to write better tests. Can this task just be to identify which
> classes need javadoc? My claim is that with T1-4 we shouldnt need any.
>
> tim
>
> Vincent Massol wrote:
>
> > From: "Vincent Massol" <vm...@oc...>
> > To: <moc...@li...>
> > Subject: [Mockobjects-java-dev] [Proposal] List of tasks for release
0.02
> > Date: Wed, 15 Aug 2001 15:14:15 +0100
> >
> > Here is a list of tasks that I propose for Release 0.02. Can you please
> > state your agreement and others that would like to see. I'll wait for
your
> > approval before entering them in the todo page :
> >
> > T1 - [doc] What are MockObjects?
> > T2 - [doc] Difference between MO and Stubs ?
> > T3 - [doc] Goal page that explains short term and long term goals of the
> > project
> > T4 - [doc] Coding conventions (in a "Developer" menu)
> > T5 - [doc] Features page
> > T6 - [doc] Release process page (in a "Developer" menu)
> > T7 - [code] add javadoc to all code where needed + add version number to
> > sources (@version @version@) + packages.html + overview.html
> > T8 - [code] Code aligned with coding conventions (and MO naming
conventions
> > already present on the web site)
> > T9 - [build] finalized build process (still need to finalize directory
> > structure + manage examples + manage extensions)
> >
> > These are the "mnimum" set of task that is can we before the release
0.02.
> >
> > Tell me also if you wish to volunteer for a given task. There can be
several
> > persons volunteering for the same task.
> >
> > I volunteer for T2, T4, T6, T9.
> >
> > Thanks
> > -Vincent
> >
> >
> > _______________________________________________
> > Mockobjects-java-users mailing list
> > Moc...@li...
> > http://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
> >
> >
>
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>

[Mockobjects-java-dev] AOP : Aspect Oriented Programming

From: Vincent M. <vm...@oc...> - 2001-08-20 13:08:26

I have discovered AOP this week end (AspectJ) and found it very very
interesting, especially for unit testing purposes. I highly suggest that you
take 30 minutes to an hour to read the "getting started" paper
(http://aspectj.org/doc/gettingStarted/index.html).

I find the idea great. In a few words, the idea is that there exist some
crosscutting aspects (hence the name: AspectJ) that encompasses several
methods. For example, let's say you want to log the entry and exits of
methods. This is a general pattern. In java, it would be very difficult to
materialize this aspect. You would have to add log statements at the
beginning and end of each method, but still you would not have captured the
pattern. Also, if you add a new method, you have to remember to add log
statements.

AspectJ let you describe aspects in its own semantic (near java). Then, you
apply the aspect compiler which will transform the code in java and invoke
the javac compiler to compile it.

It is very very powerful. You can say things like verify that such method is
only called by such other method when it is in such context. There are
better examples (with code) given in the paper highlighted above.

Just wanted to let you know
-Vincent

[Mockobjects-java-dev] Coding conventions for the sources

From: Vincent M. <vm...@oc...> - 2001-08-20 14:31:16

Can we agree on some coding conventions for the sources ?
I propose the following :
http://jakarta.apache.org/commons/cactus/coding_conventions.html, except for
items 11 and 12.

Tell me if this is ok and acceptable.

I have looked briefly at the existing code and the major differences are :
* brackets for classes and methods. For example (in
AbstractExpectation.java) :

    protected void assertEquals(
        String msg,
        int expectedValue,
        int actualValue) {
        assertEquals(msg, new Integer(expectedValue), new
Integer(actualValue));
    }

I would propose to change it to :

    protected void assertEquals(String msg, int expectedValue, int
actualValue)
   {
        assertEquals(msg, new Integer(expectedValue), new
Integer(actualValue));
    }

which I find more readable. and you ?

* class variable namings. For the moment all class variables are prefixed
with "my". I'm not sure why but it looks strange. Are they really yours ?
:-). The compromise that I have found on other project (not my preference
but it seems it is the majority's) is : Sun java coding conventions for
class variables (i.e. just the name), use this.<variable> when using them
and method parameter prefixed by "the" (ex: theMessage)

Tell me what coding conventions you'd like and let's do it. Can you please
answer to all 10 points as say if you're ok or if you want to change it and
what for.

Thanks
-Vincent

Re: [Mockobjects-java-dev] Coding conventions for the sources

From: Steve F. <st...@m3...> - 2001-08-22 01:10:11

MS4gU29tZXRpbWVzIEkgc3RhcnQgY2xhc3MgYW5kIG1ldGhvZCBicmFjZXMgb24gdGhlIHNhbWUg
bGluZS4gRGVwZW5kcyBvbiBob3cgY29tcGxpY2F0ZWQgdGhlIHNpZ25hdHVyZSBpcy4gQ29tcGFj
dCBpcyBiZXR0ZXIuDQo0LiB3ZSBkb24ndCBiZWxpZXZlIHNvIG11Y2ggaW4gamF2YWRvYy4gdGhh
dCdzIHdoeSB3ZSBzaGlwIHRoZSBzb3VyY2VzIGFuZCB0ZXN0cy4NCjcuIEkgdXNlZCB0byBsaWtl
IHRoZSAndGhpcy4nIGNvbnZlbnRpb24sIGJ1dCB3ZW50IG9mZiBpdC4gSSBkb24ndCBmZWVsIHRv
byBzdHJvbmdseS4gVGhlIGFkdmFudGFnZSBvZiBhIHByZWZpeCwgc3VjaCBhcyAnbXknIGlzIHRo
YXQgY29tcGxldGlvbiBpcyBtb3JlIGZvY3Vzc2VkLCBlc3BlY2lhbGx5IG9uIGEgbGFyZ2UgY2xh
c3MuDQo4LiBtZXRob2QgcGFyYW1ldGVycyBzaG91bGQgbm90IGNsYXNoIHdpdGggYSBjbGFzcyB2
YXJpYWJsZSwgb3IgYmUgcHJlZmFjZWQgYnkgJ2EnLCBub3QgJ3RoZScNCjkuIDc4IGNoYXJhY3Rl
cnMgcGVyIGxpbmUNCjExLiBMb2dnaW5nIGlzbid0IHJlYWxseSBhcHByb3ByaWF0ZS4NCjEyLiAn
dGhyb3dzJyBjbGF1c2VzIG1ha2UgZXhwbGljaXQgc3RhdGVtZW50cyBhYm91dCB0aGUgaW1wbGVt
ZW50YXRpb24gb2YgeW91ciBjb2RlLiB0aHJvd2luZyBleGNlcHRpb25zIHN0cmFpZ2h0IHRocm91
Z2ggY2FuIHNvbWV0aW1lcyBiZSB0aGUgYmVzdCB0aGluZyB0byBkbywgZS5nLiBmb3IgSU8uIEVh
Y2ggZnJhbWV3b3JrIHNob3VsZCBoYXZlIGEgYmFzZSBleGNlcHRpb24gY2xhc3MuIGV0Yy4NCg0K
DQo=

Re: [Mockobjects-java-dev] Coding conventions for the sources

From: Vincent M. <vm...@oc...> - 2001-08-22 06:49:55

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 22, 2001 2:09 AM
Subject: Re: [Mockobjects-java-dev] Coding conventions for the sources

> 1. Sometimes I start class and method braces on the same line. Depends on
how complicated the signature is. Compact is better.

what do you mean sometimes ? We need to choose ... and I don't agree that
compact is better. For me, the more readable is the best, compacity was an
issue when we had not enough memory ...

I prefer :

out.println("aaa");
out.println("bb");

than

out.println("aaa");out.println("bb");

> 4. we don't believe so much in javadoc. that's why we ship the sources and
tests.

Yes, you already told me this ... :) But you've never answer the question I
asked Tim (and you) ... Which was :

"
Tim (and Steve), how often do you look at the JDK source code when you need
to
understand how the BufferedReader.readLine() methods works and what it
returns if there is no more data to be read from the stream ?

Personnally I don't (although it is available, I even have it on my machine)
and I prefer to look at the javadoc !

Want to make a bet on how people do it ? :-)
"

I agree to some extent that javadoc won't be needed for mock implementation
but I don't agree for core classes. But don't worry I can do it myself if
you don't want to do it. It is always better that someone external write it
because that person will know what's difficult to understand.

> 7. I used to like the 'this.' convention, but went off it. I don't feel
too strongly. The advantage of a prefix, such as 'my' is that completion is
more focussed, especially on a large class.

Personnally, I liked "m_XXXX" but on the last 5 projects I've worked on,
almost everyone else was against me ... and I accepted their choice to use
the Sun convention (no prefix). Shall we go for that or do you want to keep
'my' ?

> 8. method parameters should not clash with a class variable, or be
prefaced by 'a', not 'the'

do you want 'a' ? It's fine with me.

> 9. 78 characters per line

ok, if you wish. I'll change that.

> 11. Logging isn't really appropriate.

err ... it is not in the coding conventions I have put .... (it was for
cactus though)

> 12. 'throws' clauses make explicit statements about the implementation of
your code. throwing exceptions straight through can sometimes be the best
thing to do, e.g. for IO. Each framework should have a base exception class.
etc.

err ... it is not in the coding conventions I have put .... (it was for
cactus though)

As we are only 2 to discuss for the time being, it's easier to agree on
something. I don't really care. Just tell me clearly what you absolutely
want, prefer or don't care. Also, please check the coding_conventions.xml in
CVS as this is our reference document.

Thanks
-Vincent

Re: [Mockobjects-java-dev] Coding conventions for the sources

From: Steve F. <st...@m3...> - 2001-08-22 08:21:03

PiA+IDEuIFNvbWV0aW1lcyBJIHN0YXJ0IGNsYXNzIGFuZCBtZXRob2QgYnJhY2VzIG9uIHRoZSBz
YW1lIGxpbmUuIERlcGVuZHMgb24NCj4gaG93IGNvbXBsaWNhdGVkIHRoZSBzaWduYXR1cmUgaXMu
IENvbXBhY3QgaXMgYmV0dGVyLg0KPiANCj4gd2hhdCBkbyB5b3UgbWVhbiBzb21ldGltZXMgPyBX
ZSBuZWVkIHRvIGNob29zZSAuLi4gYW5kIEkgZG9uJ3QgYWdyZWUgdGhhdA0KPiBjb21wYWN0IGlz
IGJldHRlci4gRm9yIG1lLCB0aGUgbW9yZSByZWFkYWJsZSBpcyB0aGUgYmVzdCwgY29tcGFjaXR5
IHdhcyBhbg0KPiBpc3N1ZSB3aGVuIHdlIGhhZCBub3QgZW5vdWdoIG1lbW9yeSAuLi4NCg0KT0su
IGJyYWNlcyBhbHdheXMgYXQgdGhlIGVuZC4gSWYgd2UgY2FuIGZvcmNlIGJyYWNlcyB0byB0aGUg
bmV4dCBsaW5lIHdoZW4gdGhlIGxpbmUgd3JhcHMgdGhhdCB3b3VsZCBiZSBuaWNlLCBidXQgbm90
IGVzc2VudGlhbC4NCg0KPiA+IDQuIHdlIGRvbid0IGJlbGlldmUgc28gbXVjaCBpbiBqYXZhZG9j
LiB0aGF0J3Mgd2h5IHdlIHNoaXAgdGhlIHNvdXJjZXMgYW5kDQo+IHRlc3RzLg0KPiAiDQo+IFRp
bSAoYW5kIFN0ZXZlKSwgaG93IG9mdGVuIGRvIHlvdSBsb29rIGF0IHRoZSBKREsgc291cmNlIGNv
ZGUgd2hlbiB5b3UgbmVlZA0KPiB0bw0KPiB1bmRlcnN0YW5kIGhvdyB0aGUgQnVmZmVyZWRSZWFk
ZXIucmVhZExpbmUoKSBtZXRob2RzIHdvcmtzIGFuZCB3aGF0IGl0DQo+IHJldHVybnMgaWYgdGhl
cmUgaXMgbm8gbW9yZSBkYXRhIHRvIGJlIHJlYWQgZnJvbSB0aGUgc3RyZWFtID8NCg0KVGhlIG1v
Y2sgbGlicmFyeSBpcyBub3QgaW4gdGhlIHNhbWUgY2F0ZWdvcnkuIEl0J3MgdmVyeSBzbWFsbCBh
bmQsIHVubGlrZSB0aGUgSkRLLCBpdCBjb21lcyB3aXRoIHVuaXQgdGVzdHMuIFdlIG5lZWQgdG8g
aW5jbHVkZSB0aGUgY29weXJpZ2h0IGJ1dCwgYWZ0ZXIgdGhhdCwgYWxsIHdlIG1pZ2h0IG5lZWQg
aXMgYSBzaG9ydCBkZXNjcmlwdGlvbiBvZiB0aGUgY2xhc3MgYXMgYSB3aG9sZS4gDQoNCkFzIGFu
IGV4ZXJjaXNlLCB3b3VsZCB5b3UgbGlrZSB0byBzaG93IHNvbWUgZG9jIHRoYXQgZG9lcyBub3Qg
anVzdCByZXByb2R1Y2UgdGhlIGNvZGU/DQoNCj4gPiA3LiBJIHVzZWQgdG8gbGlrZSB0aGUgJ3Ro
aXMuJyBjb252ZW50aW9uLCBidXQgd2VudCBvZmYgaXQuIEkgZG9uJ3QgZmVlbA0KPiB0b28gc3Ry
b25nbHkuIFRoZSBhZHZhbnRhZ2Ugb2YgYSBwcmVmaXgsIHN1Y2ggYXMgJ215JyBpcyB0aGF0IGNv
bXBsZXRpb24gaXMNCj4gbW9yZSBmb2N1c3NlZCwgZXNwZWNpYWxseSBvbiBhIGxhcmdlIGNsYXNz
Lg0KPiANCj4gUGVyc29ubmFsbHksIEkgbGlrZWQgIm1fWFhYWCIgYnV0IG9uIHRoZSBsYXN0IDUg
cHJvamVjdHMgSSd2ZSB3b3JrZWQgb24sDQo+IGFsbW9zdCBldmVyeW9uZSBlbHNlIHdhcyBhZ2Fp
bnN0IG1lIC4uLiBhbmQgSSBhY2NlcHRlZCB0aGVpciBjaG9pY2UgdG8gdXNlDQo+IHRoZSBTdW4g
Y29udmVudGlvbiAobm8gcHJlZml4KS4gU2hhbGwgd2UgZ28gZm9yIHRoYXQgb3IgZG8geW91IHdh
bnQgdG8ga2VlcA0KPiAnbXknID8NCg0Kbm90ICdtXycuIExldCdzIHN0aWNrIHdpdGggJ215JyBm
b3Igbm93IGJlY2F1c2UgSSBjYW4ndCBiZSBib3RoZXJlZCB0byBjaGFuZ2UgdGhlIGNvZGUuDQoN
CiANCj4gPiA4LiBtZXRob2QgcGFyYW1ldGVycyBzaG91bGQgbm90IGNsYXNoIHdpdGggYSBjbGFz
cyB2YXJpYWJsZSwgb3IgYmUNCj4gcHJlZmFjZWQgYnkgJ2EnLCBub3QgJ3RoZScNCj4gZG8geW91
IHdhbnQgJ2EnID8gSXQncyBmaW5lIHdpdGggbWUuDQoNCmdvb2QuIHNtYWxsdGFsayBsZWdhY3ku
DQoNCj4gPiA5LiA3OCBjaGFyYWN0ZXJzIHBlciBsaW5lDQo+IG9rLCBpZiB5b3Ugd2lzaC4gSSds
bCBjaGFuZ2UgdGhhdC4NCg0Kc29tZXRpbWVzIGl0IHdyYXBzIGJldHRlcg0KDQo+IGVyciAuLi4g
aXQgaXMgbm90IGluIHRoZSBjb2RpbmcgY29udmVudGlvbnMgSSBoYXZlIHB1dCAuLi4uIChpdCB3
YXMgZm9yIGNhY3R1cyB0aG91Z2gpDQpJIGZvbGxvd2VkIHRoZSBsaW5rIHlvdSBzZW50Lg0KDQpB
bnl0aGluZyBlbHNlPw0KDQoNCg==