mockobjects-java-dev — For people who are working on the implementation of the java version

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

[Vincent M. <vm...@oc...>]

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
>

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

[Vincent M. <vm...@oc...>]

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

[Tim M. <tim...@po...>]

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

[Vincent M. <vm...@oc...>]

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


> I'm a bit concerned if we cannot release _anything_ before all of this is
done, given our current rate of progress. I agree that all of this should be
part of a proper release, but we have ongoing code changes to the library
which need to be released. Can we have a mechanism for interim releases as
well as official releases?

I don't think T1-T9 are big tasks. Documentation as important as code if not
even more ... and for the time being there isn't much ... So I don't agree
that we need to release code prior to documentation. The code is in CVS and
accessible to anyone. Interim release would correspond to snapshots (or
nightly builds), yes that's something that we could do but I don't think it
is the issue.

What source do you want to release ?

>
> T1 should be the original paper, perhaps with extensions.

ok

> T2 I should take a look at that too
> T3 Guess I could do that
> T4 Can you extend the current version

I was thinking about coding standards to normal java code not Mock Objects
naming conventions but yes we can extend the current although I am not sure
they belong to the same document.

> T5 not sure what to put there.

easy : Servlet API mock implementation that does this this and this, JDBC
one, ... Expectation classes for this, .....

> T7 versioning, sure. But we should be releasing sources, not javadoc,
except for occasional notes. Maybe a common header that says Just Look at
the Code?

I mentioned "where needed". That would be to the core framework and may not
be needed to the mock implementations themselves ?

> T8 getting there.

you see we're almost there.
-Vincent

>
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@oc...>
> To: <moc...@li...>
> Sent: Wednesday, August 15, 2001 3:14 PM
> Subject: [Mockobjects-java-dev] [Proposal] List of tasks for release 0.02
>
>
> > 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
> >
> 2¡rjzS,´'yuS²q®z¶-²­¢-³²~¡n¶½

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

[Steve F. <st...@m3...>]

amF2YSwgc3VyZS4NCkkgc3RpbGwgaGF2ZSBzb21lIHN0dWZmIGluIHRoZSBkb2MgZGlyZWN0b3J5
DQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiVmluY2VudCBNYXNzb2wi
IDx2bWFzc29sQG9jdG8uY29tPg0KVG86IDxtb2Nrb2JqZWN0cy1qYXZhLWRldkBsaXN0cy5zb3Vy
Y2Vmb3JnZS5uZXQ+DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAxNSwgMjAwMSAzOjMzIFBNDQpT
dWJqZWN0OiBSZTogW01vY2tvYmplY3RzLWphdmEtZGV2XSBbUHJvcG9zYWxdIExpc3Qgb2YgdGFz
a3MgZm9yIHJlbGVhc2UgMC4wMg0KDQoNCj4gVDEwIC0gUmVtb3ZlIHRoZSAiamF2YSIgYW5kICJk
b2MiIENWUyBtb2R1bGVzIG9uIFNGDQoNCg==

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

[Steve F. <st...@m3...>]

SSdtIGEgYml0IGNvbmNlcm5lZCBpZiB3ZSBjYW5ub3QgcmVsZWFzZSBfYW55dGhpbmdfIGJlZm9y
ZSBhbGwgb2YgdGhpcyBpcyBkb25lLCBnaXZlbiBvdXIgY3VycmVudCByYXRlIG9mIHByb2dyZXNz
LiBJIGFncmVlIHRoYXQgYWxsIG9mIHRoaXMgc2hvdWxkIGJlIHBhcnQgb2YgYSBwcm9wZXIgcmVs
ZWFzZSwgYnV0IHdlIGhhdmUgb25nb2luZyBjb2RlIGNoYW5nZXMgdG8gdGhlIGxpYnJhcnkgd2hp
Y2ggbmVlZCB0byBiZSByZWxlYXNlZC4gQ2FuIHdlIGhhdmUgYSBtZWNoYW5pc20gZm9yIGludGVy
aW0gcmVsZWFzZXMgYXMgd2VsbCBhcyBvZmZpY2lhbCByZWxlYXNlcz8NCg0KVDEgc2hvdWxkIGJl
IHRoZSBvcmlnaW5hbCBwYXBlciwgcGVyaGFwcyB3aXRoIGV4dGVuc2lvbnMuDQpUMiBJIHNob3Vs
ZCB0YWtlIGEgbG9vayBhdCB0aGF0IHRvbw0KVDMgR3Vlc3MgSSBjb3VsZCBkbyB0aGF0DQpUNCBD
YW4geW91IGV4dGVuZCB0aGUgY3VycmVudCB2ZXJzaW9uDQpUNSBub3Qgc3VyZSB3aGF0IHRvIHB1
dCB0aGVyZS4NClQ3IHZlcnNpb25pbmcsIHN1cmUuIEJ1dCB3ZSBzaG91bGQgYmUgcmVsZWFzaW5n
IHNvdXJjZXMsIG5vdCBqYXZhZG9jLCBleGNlcHQgZm9yIG9jY2FzaW9uYWwgbm90ZXMuIE1heWJl
IGEgY29tbW9uIGhlYWRlciB0aGF0IHNheXMgSnVzdCBMb29rIGF0IHRoZSBDb2RlPw0KVDggZ2V0
dGluZyB0aGVyZS4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlZp
bmNlbnQgTWFzc29sIiA8dm1hc3NvbEBvY3RvLmNvbT4NClRvOiA8bW9ja29iamVjdHMtamF2YS1k
ZXZAbGlzdHMuc291cmNlZm9yZ2UubmV0Pg0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTUsIDIw
MDEgMzoxNCBQTQ0KU3ViamVjdDogW01vY2tvYmplY3RzLWphdmEtZGV2XSBbUHJvcG9zYWxdIExp
c3Qgb2YgdGFza3MgZm9yIHJlbGVhc2UgMC4wMg0KDQoNCj4gSGVyZSBpcyBhIGxpc3Qgb2YgdGFz
a3MgdGhhdCBJIHByb3Bvc2UgZm9yIFJlbGVhc2UgMC4wMi4gQ2FuIHlvdSBwbGVhc2UNCj4gc3Rh
dGUgeW91ciBhZ3JlZW1lbnQgYW5kIG90aGVycyB0aGF0IHdvdWxkIGxpa2UgdG8gc2VlLiBJJ2xs
IHdhaXQgZm9yIHlvdXINCj4gYXBwcm92YWwgYmVmb3JlIGVudGVyaW5nIHRoZW0gaW4gdGhlIHRv
ZG8gcGFnZSA6DQo+IA0KPiBUMSAtIFtkb2NdIFdoYXQgYXJlIE1vY2tPYmplY3RzPw0KPiBUMiAt
IFtkb2NdIERpZmZlcmVuY2UgYmV0d2VlbiBNTyBhbmQgU3R1YnMgPw0KPiBUMyAtIFtkb2NdIEdv
YWwgcGFnZSB0aGF0IGV4cGxhaW5zIHNob3J0IHRlcm0gYW5kIGxvbmcgdGVybSBnb2FscyBvZiB0
aGUNCj4gcHJvamVjdA0KPiBUNCAtIFtkb2NdIENvZGluZyBjb252ZW50aW9ucyAoaW4gYSAiRGV2
ZWxvcGVyIiBtZW51KQ0KPiBUNSAtIFtkb2NdIEZlYXR1cmVzIHBhZ2UNCj4gVDYgLSBbZG9jXSBS
ZWxlYXNlIHByb2Nlc3MgcGFnZSAoaW4gYSAiRGV2ZWxvcGVyIiBtZW51KQ0KPiBUNyAtIFtjb2Rl
XSBhZGQgamF2YWRvYyB0byBhbGwgY29kZSB3aGVyZSBuZWVkZWQgKyBhZGQgdmVyc2lvbiBudW1i
ZXIgdG8NCj4gc291cmNlcyAoQHZlcnNpb24gQHZlcnNpb25AKSArIHBhY2thZ2VzLmh0bWwgKyBv
dmVydmlldy5odG1sDQo+IFQ4IC0gW2NvZGVdIENvZGUgYWxpZ25lZCB3aXRoIGNvZGluZyBjb252
ZW50aW9ucyAoYW5kIE1PIG5hbWluZyBjb252ZW50aW9ucw0KPiBhbHJlYWR5IHByZXNlbnQgb24g
dGhlIHdlYiBzaXRlKQ0KPiBUOSAtIFtidWlsZF0gZmluYWxpemVkIGJ1aWxkIHByb2Nlc3MgKHN0
aWxsIG5lZWQgdG8gZmluYWxpemUgZGlyZWN0b3J5DQo+IHN0cnVjdHVyZSArIG1hbmFnZSBleGFt
cGxlcyArIG1hbmFnZSBleHRlbnNpb25zKQ0KPiANCj4gVGhlc2UgYXJlIHRoZSAibW5pbXVtIiBz
ZXQgb2YgdGFzayB0aGF0IGlzIGNhbiB3ZSBiZWZvcmUgdGhlIHJlbGVhc2UgMC4wMi4NCj4gDQo+
IFRlbGwgbWUgYWxzbyBpZiB5b3Ugd2lzaCB0byB2b2x1bnRlZXIgZm9yIGEgZ2l2ZW4gdGFzay4g
VGhlcmUgY2FuIGJlIHNldmVyYWwNCj4gcGVyc29ucyB2b2x1bnRlZXJpbmcgZm9yIHRoZSBzYW1l
IHRhc2suDQo+IA0KPiBJIHZvbHVudGVlciBmb3IgVDIsIFQ0LCBUNiwgVDkuDQo+IA0KPiBUaGFu
a3MNCj4gLVZpbmNlbnQNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPiBNb2Nrb2JqZWN0cy1qYXZhLXVzZXJzIG1haWxpbmcgbGlzdA0K
PiBNb2Nrb2JqZWN0cy1qYXZhLXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldA0KPiBodHRwOi8v
bGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL21vY2tvYmplY3RzLWphdmEtdXNl
cnMNCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQo+IE1vY2tvYmplY3RzLWphdmEtZGV2IG1haWxpbmcgbGlzdA0KPiBNb2Nr
b2JqZWN0cy1qYXZhLWRldkBsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCj4gaHR0cDovL2xpc3RzLnNv
dXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9tb2Nrb2JqZWN0cy1qYXZhLWRldg0KPiANCg==

Re: [Mockobjects-java-dev] Advantage for In-Container vs Mock ?

[Thomas C. <ald...@ne...>]

Steve

Thank you for your feedback.

"why would you assert the verify? The verify method should throw an
AssertionFailedException if it fails."

Agreed.

"why don't you use an ExpectationCounter? Also, how does the check method
differ from using Verifiable, which is a consistent interface we use across
the library (and is searcheable by reflection)."

Sure, let's use the ExpectationCounter with the inc() and verify() methods.
I used CallCounter simply to show that the goal for the check() method is
not to do any verification of parameters used in method calls or of  return
values, but simply to check that the *number* of method calls is correct.
Most of the verification of correct parameters and such is done in the
overridden methods themselves.

As long as the references in the outer class are final, we can use any of
the Expectation-implementing classes of com.mockobjects.* *anywhere* in the
test, including in the anonymous inner class methods, and call their verify
methods at the end of test as appropriate. So far, through refactoring and
demeter-based method design of the production classes, my experience is that
the simple counter suffices. Do you have any complex class examples where
doing verifications in the inner class and checking the number of method
calls via a counter is not adequate?

"Are you saying that the trick is to implement in the inner class only those
methods you need for the current test? If so, that need clarifying."

This is precisely the point. We only override the methods we need for the
current test and make our assertions within those overridden methods. We can
also, as above, use an ExpectationCounter to check message calls. If this is
not clear, what do you suggest to make sure it is clear?

Also, remember that the current context is pre-JDK 1.3 *with* interfaces to
mock. If we use JDK 1.3, we use a proxy and declare an invocation handler as
an anonymous class - we do not need to provide *any* mock implementation
class and only have to implement handling for the specific methods used by
the method being tested.

Putting JDK 1.3 aside, the mock objects project, AFAIK, is dependent on the
existence of interfaces for everything that is mocked. IMO, this is an
unrealistic expectation of a project where it is not generally useful to
have an interface for every single class, especially package protected
classes. Therefore, there are some classes for which we want to mock a
subset of their methods for a particular test, but have no interface. The
inner class patterns allow the overriding to facilitate this. Moreover, when
testing a method of a particular class, we can use an anonymous inner class
to override other methods of the *same class* as necessary to make
fine-grained assertions and test our expectations. How do we do this
without the patterns described?

Tom

Re: [Mockobjects-java-dev] mailing list configuration

[Vincent M. <vm...@oc...>]

[Aside: If your client don't do filtering, you're lost ! You should change
client ... :-)
I am subscribed to 20 mailing-lists and receive about 2000 mails *per day*.
Imagine my life without filtering, impossible ... And I think most people
participating to open source are also subscribed to several other lists.]

But this is not important. I asked, just in case, everyone would agree (I
don't even know if it is possible to change ?). Let's keep it the way it is
now .... :-)

Thanks
-Vincent

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 15, 2001 6:55 PM
Subject: Re: [Mockobjects-java-dev] mailing list configuration


> Not sure.
>
> Most of the mailing lists seem to do this nowadays to make it easier for
people to cope with multiple lists.
>
> I prefer it because I'm using IMAP and my client won't do automatic
filtering.
>
> What do other people think?
> Steve
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@oc...>
> To: <moc...@li...>
> Sent: Wednesday, August 15, 2001 3:15 PM
> Subject: [Mockobjects-java-dev] mailing list configuration
>
>
> > Is it possible to change the mailing list configuration so that it does
not
> > prepend the name of the list to each message sent ? I find this a bit
> > annoying ...
> > Thanks
> > -Vincent
> >
> >
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> 2¡rjzS,´'yuS²q®z¶-²­¢-³²~¡n¶½

Re: [Mockobjects-java-dev] Advantage for In-Container vs Mock ?

[Steve F. <st...@m3...>]

RnJvbTogIlRob21hcyBDYWxpdmVyYSIgPGFsZGhlb3J0ZUBuZXR6ZXJvLmNvbT4NCj4gICAgIFN0
cmluZyByZXN1bHQgPSBteU9iamVjdC5zb21lTWV0aG9kKCk7DQo+ICAgICBhc3NlcnRFcXVhbHMo
Ii4uLiIsIHJlc3VsdCk7DQo+ICAgICBhc3NlcnQobW9jay52ZXJpZnkoKSk7DQoNCndoeSB3b3Vs
ZCB5b3UgYXNzZXJ0IHRoZSB2ZXJpZnk/IFRoZSB2ZXJpZnkgbWV0aG9kIHNob3VsZCB0aHJvdyBh
biBBc3NlcnRpb25GYWlsZWRFeGNlcHRpb24gaWYgaXQgZmFpbHMuDQoNCj4gVW5mb3J0dW5hdGVs
eSwgdGhpcyBkb2VzIG5vdCBhbnN3ZXIgdGhlIHF1ZXN0aW9uIG9mLCAiV2hhdCBoYXBwZW5zIGlm
DQo+IG1ldGhvZCBBQUEgaXMgbmV2ZXIgY2FsbGVkLCBidXQgdGhlIGNhbGwgYWZmZWN0cyB0aGUg
c3RhdGUgb2Ygb2JqZWN0IHl5eQ0KPiBhbmQgaXMgcmVxdWlyZWQgYnkgY29udHJhY3Q/IiBJZiBl
c3NlbnRpYWwsIHdlIGNhbiB1c2UgYSBzbWFsbCBoZWxwZXINCj4gY2xhc3MgdG8gY291bnQgY2Fs
bHM6DQo+IA0KPiBwdWJsaWMgY2xhc3MgQ2FsbENvdW50KCkgew0KPiANCj4gICAgIGludCByZXF1
aXJlZDsNCj4gICAgIA0KPiAgICAgcHVibGljIENhbGxDb3VudChpbnQgcmVxdWlyZWQpIHsNCj4g
ICAgICAgICB0aGlzLnJlcXVpcmVkID0gcmVxdWlyZWQ7DQo+ICAgICB9DQo+ICAgICANCj4gICAg
IHB1YmxpYyB2b2lkIGFkZCgpIHsNCj4gICAgICAgICByZXF1aXJlZC0tOw0KPiAgICAgfQ0KPiAg
ICAgDQo+ICAgICBwdWJsaWMgYm9vbGVhbiBjaGVjaygpIHsNCj4gICAgICAgICByZXR1cm4gcmVx
dWlyZWQgPT0gMDsNCj4gICAgIH0NCj4gDQo+IH0NCg0Kd2h5IGRvbid0IHlvdSB1c2UgYW4gRXhw
ZWN0YXRpb25Db3VudGVyPyBBbHNvLCBob3cgZG9lcyB0aGUgY2hlY2sgbWV0aG9kIGRpZmZlciBm
cm9tIHVzaW5nIFZlcmlmaWFibGUsIHdoaWNoIGlzIGEgY29uc2lzdGVudCBpbnRlcmZhY2Ugd2Ug
dXNlIGFjcm9zcyB0aGUgbGlicmFyeSAoYW5kIGlzIHNlYXJjaGVhYmxlIGJ5IHJlZmxlY3Rpb24p
Lg0KDQo+IFRodXMsIHdpdGhvdXQgdGhlIGNhbGwgY291bnRlcnMsIHlvdSBjYW4gbWFrZSB1c2Ug
b2YgYQ0KPiBWZXJpZmlhYmxlLWxpa2UgaW50ZXJmYWNlLiBXaXRoIHRoZSBjYWxsIGNvdW50ZXJz
LCB5b3UgY2FuIHB1dCBhc2lkZQ0KPiBWZXJpZmlhYmxlIGNvbXBsZXRlbHkgd2hpbGUgbWFraW5n
IG1vc3Qgb2YgeW91ciBhc3NlcnRpb25zIGRpcmVjdGx5IGluDQo+IG1ldGhvZHMgb2YgdGhlIGFu
b255bW91cyBjbGFzcy4NCg0Kc29ycnkuIEkgZG9uJ3QgdW5kZXJzdGFuZC4gVG8gY2hlY2sgZm9y
IG1pc3NpbmcgdmFsdWVzIChvciBjYWxscykgeW91IGhhdmUgdG8gY2FsbCBzb21lIGtpbmQgb2Yg
Y2hlY2tpbmcgbWVjaGFuaXNtIGF0IHRoZSBlbmQgb2YgdGhlIHRlc3QuIFlvdSBjYW4gZWl0aGVy
IHdyaXRlIHlvdXJzZWxmIGEgY2hlY2sgbWV0aG9kIG9yIHVzZSBzb21lIG9mIG91ciBWZXJpZmlh
YmxlIGluZnJhc3RydWN0dXJlLiBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIGRpZmZlcmVuY2UuIEkg
YWxzbyBkb24ndCBzZWUgd2h5IHRoZSBpbm5lciBjbGFzcyBpcyBtb3JlIGVmZmljaWVudC4NCg0K
QXMgZmFyIGFzIEkgY2FuIHRlbGwgdGhlIGlubmVyIGNsYXNzZXMgaW1wbGVtZW50IG11Y2ggdGhl
IHNhbWUgY29kZSBhcyB3ZSBkbyB3aXRoIG91ciBtb2NrIGxpYnJhcmllcywgZXhjZXB0IHRoYXQg
dGhleSBtYWtlcyB0aGUgdGVzdCBtZXRob2RzIGxvbmdlci4gSSBhbHNvIGRvbid0IHF1aXRlIHNl
ZSBob3cgaXQgd291bGQgc2NhbGUgdXAgdG8gbW9yZSBjb21wbGV4IG9iamVjdHMuIEFyZSB5b3Ug
c2F5aW5nIHRoYXQgdGhlIHRyaWNrIGlzIHRvIGltcGxlbWVudCBpbiB0aGUgaW5uZXIgY2xhc3Mg
b25seSB0aG9zZSBtZXRob2RzIHlvdSBuZWVkIGZvciB0aGUgY3VycmVudCB0ZXN0PyBJZiBzbywg
dGhhdCBuZWVkIGNsYXJpZnlpbmcuDQoNClN0ZXZlDQoNCg==

Re: [Mockobjects-java-dev] mailing list configuration

[Steve F. <st...@m3...>]

Tm90IHN1cmUuDQoNCk1vc3Qgb2YgdGhlIG1haWxpbmcgbGlzdHMgc2VlbSB0byBkbyB0aGlzIG5v
d2FkYXlzIHRvIG1ha2UgaXQgZWFzaWVyIGZvciBwZW9wbGUgdG8gY29wZSB3aXRoIG11bHRpcGxl
IGxpc3RzLiANCg0KSSBwcmVmZXIgaXQgYmVjYXVzZSBJJ20gdXNpbmcgSU1BUCBhbmQgbXkgY2xp
ZW50IHdvbid0IGRvIGF1dG9tYXRpYyBmaWx0ZXJpbmcuDQoNCldoYXQgZG8gb3RoZXIgcGVvcGxl
IHRoaW5rPw0KU3RldmUNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJW
aW5jZW50IE1hc3NvbCIgPHZtYXNzb2xAb2N0by5jb20+DQpUbzogPG1vY2tvYmplY3RzLWphdmEt
ZGV2QGxpc3RzLnNvdXJjZWZvcmdlLm5ldD4NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDE1LCAy
MDAxIDM6MTUgUE0NClN1YmplY3Q6IFtNb2Nrb2JqZWN0cy1qYXZhLWRldl0gbWFpbGluZyBsaXN0
IGNvbmZpZ3VyYXRpb24NCg0KDQo+IElzIGl0IHBvc3NpYmxlIHRvIGNoYW5nZSB0aGUgbWFpbGlu
ZyBsaXN0IGNvbmZpZ3VyYXRpb24gc28gdGhhdCBpdCBkb2VzIG5vdA0KPiBwcmVwZW5kIHRoZSBu
YW1lIG9mIHRoZSBsaXN0IHRvIGVhY2ggbWVzc2FnZSBzZW50ID8gSSBmaW5kIHRoaXMgYSBiaXQN
Cj4gYW5ub3lpbmcgLi4uDQo+IFRoYW5rcw0KPiAtVmluY2VudA0KPiANCj4gDQo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE1vY2tvYmplY3RzLWph
dmEtZGV2IG1haWxpbmcgbGlzdA0KPiBNb2Nrb2JqZWN0cy1qYXZhLWRldkBsaXN0cy5zb3VyY2Vm
b3JnZS5uZXQNCj4gaHR0cDovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby9t
b2Nrb2JqZWN0cy1qYXZhLWRldg0KPiANCg==

Re: [Mockobjects-java-dev] Advantage for In-Container vs Mock ?

[Thomas C. <ald...@ne...>]

Vincent

"I like the dynamic proxy because it enables to skip the static mock
implementation generation step. Even if you don't have an interface you
can still extend a class."

The implementation of java.lang.reflect.Proxy requires an interface -
you cannot extend an implementation class with Proxy. However, you can
override methods of an implementation class (in any JDK, AFAIK), with
the anonymous inner class testing pattern, but you cannot add callable
methods to the class' interface with an *anonymous* inner class. You can
also use this latter pattern to extend and test interfaces prior to JDK
1.3 *if and only if* a compilable mock implementation exists, though
this mock implementation can simply return null or do nothing for all
methods as return values require (thus relatively easy to generate).

"public void testSomething()
{
  MockYYY mock = new MockYYY();
  mock.setActualValueXXX("text/html");
  mock.setActualValueZZZ(true);
...
  // set the expectations on the mock object (if need be)
  mock.setExpectedValueAAA("something");
...
  // the method to unit test that calls XXX
  // and ZZZ as part of it's logic
  String result = myObject.someMethod();
...
  // then the asserts, which can be a mix of junit asserts and
  // verifying against the expectations set on the mock object
  assertEquals("...", result);
  mock.verify();
}"

If I understand this correctly, this is a good spot to do a side-by-side
comparison of pieces of the test above with the patterns. One way,
closest to that in the last version of the article draft I posted here:

public void testSomething() {

    MockYYY mock = new MockYYY() { // Implements a verifiable interface
    
        private boolean called;
        
        String XXX() {
            return "text/html");
        }
        
        boolean ZZZ() {
            return true;
        }
        
        void AAA(String someString) {
            assertEquals("something", someString);
            called = true;
        }
        
        boolean verify() {
            return called;
        }
        
    };
    
    String result = myObject.someMethod();
    assertEquals("...", result);
    assert(mock.verify());
}

However, this is more efficient and renders the Verifiable interface
unnecessary:

public void testSomething() {

    MockYYY mock = new MockYYY() {
    
        String XXX() {
            return "text/html");
        }
        
        boolean ZZZ() {
            return true;
        }
        
        void AAA(String someString) {
            assertEquals("something", something);
        }
        
    };
    
    String result = myObject.someMethod();
    assertEquals("...", result);
}

Unfortunately, this does not answer the question of, "What happens if
method AAA is never called, but the call affects the state of object yyy
and is required by contract?" If essential, we can use a small helper
class to count calls:

public class CallCount() {

    int required;
    
    public CallCount(int required) {
        this.required = required;
    }
    
    public void add() {
        required--;
    }
    
    public boolean check() {
        return required == 0;
    }

}

And use it thus:

public void testSomething() {

    final CallCount calls = new CallCount(1);
    
    MockYYY mock = new MockYYY() {
    
        String XXX() {
            return "text/html");
        }
        
        boolean ZZZ() {
            return true;
        }
        
        void AAA(String someString) {
            assertEquals("something", something);
            calls.add();
        }
        
    };
    
    String result = myObject.someMethod();
    assertEquals("...", result);
    assert(calls.check());
}

There still remains a slight chance, where there are two or more methods
to call in the mock object and at least one of those methods is supposed
to get called more than once, that the test might not catch the
*incorrect* method call frequency. In my experience, this is fairly rare
except for writing to output streams where a count of the number of
lines or number of times printed is not generally useful. Moreover,
calling the same method of another object, aside from some basic system
classes, more than once in the same method is a symptom of poor method
design. However, if we really must be sure, a slightly more advanced
call counter could suffice. To prepare:

CallCountMap calls = new CallCountMap();
calls.set("AAA", 6);
calls.set("BBB", 4);

To record in an anonymous class method:

calls.add("AAA");

To check:

assert(calls.check());

Of, if call the check method is implemented to cause an assertion
failure, the additional assert is not necessary:

calls.check();

Thus, without the call counters, you can make use of a
Verifiable-like interface. With the call counters, you can put aside
Verifiable completely while making most of your assertions directly in
methods of the anonymous class.

Now, there are some subtle points regarding "expectation folding" that I
am waiting to hear back from Tim and Steve on to see if they have seen
situations where this breaks down, but it is working for me thus far and
causing some refactoring of production classes that proves useful later
on. Also, if there *are* complex expectations, you can always replace
the CallCountMap in the above with an expectation monitor class perhaps
build on some of the expectation classes currently available in the mock
objects project.

"We probably need to work on a real life example"

Indeed. I shall stay tuned.

"The idea is simply that with the above described generic mechanism
there is no need to inner classes at all."

Agreed in theory with the generic mechanism you described, but it seems
to me that the generic mechanism is not trivial, requiring a lot of code
and a relatively large library to pull off as well as the prospect of
complicated code generation and compilation.

Tom

Re: [Mockobjects-java-dev] mailing list configuration

[Vincent M. <vm...@oc...>]

done!
-Vincent

----- Original Message ----- 
From: "Brekke, Jeff" <Jef...@qg...>
To: <moc...@li...>
Sent: Wednesday, August 15, 2001 3:24 PM
Subject: RE: [Mockobjects-java-dev] mailing list configuration


> And can we get the email which sends a diff to perform a diff -u so the
> changes are more easily readable?
> 
> -----------------------------------------------------------------
>     Throw away my code, but never, never throw away my tests.
> -----------------------------------------------------------------
> Jeffrey D. Brekke                                   Quad/Graphics
> Jef...@qg...                              http://www.qg.com
> -----------------------------------------------------------------
> 
> 
> 
> > -----Original Message-----
> > From: Vincent Massol [mailto:vm...@oc...]
> > Sent: Wednesday, August 15, 2001 9:15 AM
> > To: moc...@li...
> > Subject: [Mockobjects-java-dev] mailing list configuration
> > 
> > 
> > Is it possible to change the mailing list configuration so 
> > that it does not
> > prepend the name of the list to each message sent ? I find this a bit
> > annoying ...
> > Thanks
> > -Vincent
> > 
> > 
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> > 
> 
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> 

[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs todo.xml,1.4,1.5

[Vincent M. <vm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv1297/doc/xdocs

Modified Files:
	todo.xml 
Log Message:
typo correction (and verify if unified diff on commits work)

Index: todo.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/todo.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- todo.xml	2001/08/15 14:51:02	1.4
+++ todo.xml	2001/08/15 15:22:28	1.5
@@ -13,7 +13,7 @@
       mailing list</link> stating your interest and 
       you'll be enrolled right away ... We're
       always looking for help ! Don't be put off if in the "Volunteer" column
-      there is already a person listed. On the contrary, the more person that
+      there is already a person listed. On the contrary, the more persons that
       participate in a given task, the better (like in pair programming, several
       sets of eyes are always better than one!). However you'll need to sync.
       with these others persons but this is easily done by posting to the

[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs todo.xml

[Vincent M. <vm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv25434/doc/xdocs

Modified Files:
	todo.xml 
Log Message:
typo (and verify that unified diff works)

***** Bogus filespec: todo.xml

unified diff (WAS Re: [Mockobjects-java-dev] mailing list configuration)

[Vincent M. <vm...@oc...>]

That would be me ... I used a syncmail script found on SF ... I just read
the perl script and it says in its usage section comments :

"
[...]
    -u
        Produce a unified diff (smaller, but harder to read).
[...]
"

:-)

However, I tend to agree with you .... will do it now ... If anyone do not
agree, tell me.

Thanks
-Vincent

----- Original Message -----
From: "Brekke, Jeff" <Jef...@qg...>
To: <moc...@li...>
Sent: Wednesday, August 15, 2001 3:24 PM
Subject: RE: [Mockobjects-java-dev] mailing list configuration


> And can we get the email which sends a diff to perform a diff -u so the
> changes are more easily readable?
>
> -----------------------------------------------------------------
>     Throw away my code, but never, never throw away my tests.
> -----------------------------------------------------------------
> Jeffrey D. Brekke                                   Quad/Graphics
> Jef...@qg...                              http://www.qg.com
> -----------------------------------------------------------------
>
>
>
> > -----Original Message-----
> > From: Vincent Massol [mailto:vm...@oc...]
> > Sent: Wednesday, August 15, 2001 9:15 AM
> > To: moc...@li...
> > Subject: [Mockobjects-java-dev] mailing list configuration
> >
> >
> > Is it possible to change the mailing list configuration so
> > that it does not
> > prepend the name of the list to each message sent ? I find this a bit
> > annoying ...
> > Thanks
> > -Vincent
> >
> >
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
>
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>

RE: [Mockobjects-java-dev] mailing list configuration

[Brekke, J. <Jef...@qg...>]

And can we get the email which sends a diff to perform a diff -u so the
changes are more easily readable?

-----------------------------------------------------------------
    Throw away my code, but never, never throw away my tests.
-----------------------------------------------------------------
Jeffrey D. Brekke                                   Quad/Graphics
Jef...@qg...                              http://www.qg.com
-----------------------------------------------------------------



> -----Original Message-----
> From: Vincent Massol [mailto:vm...@oc...]
> Sent: Wednesday, August 15, 2001 9:15 AM
> To: moc...@li...
> Subject: [Mockobjects-java-dev] mailing list configuration
> 
> 
> Is it possible to change the mailing list configuration so 
> that it does not
> prepend the name of the list to each message sent ? I find this a bit
> annoying ...
> Thanks
> -Vincent
> 
> 
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> 

[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs todo.xml,1.2,1.3

[Vincent M. <vm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv20523/doc/xdocs

Modified Files:
	todo.xml 
Log Message:
prepare for release 0.02 task list

Index: todo.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/todo.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** todo.xml	2001/08/01 10:19:02	1.2
--- todo.xml	2001/08/15 14:32:32	1.3
***************
*** 25,42 ****
    </s1>
  
!   <version title="Version 0.1">
  
      <!-- In order to assign someone to a task, add the 'assigned-go'
           attribute to the action tag. Ex:
           action assigned-to="Vincent Massol, Steve Freeman" -->
- 
-     <category title="Design">
-       <action>
-         Write a common coding and naming convention (for example names of
-         mock initialization methods like <code>setupAddParameter()</code>,
-         name of methods for setting expectations, ...) and reformat all the 
-         existing code.
-       </action>
-     </category>
  
      <category title="Code">
--- 25,33 ----
    </s1>
  
!   <version title="Version 0.02">
  
      <!-- In order to assign someone to a task, add the 'assigned-go'
           attribute to the action tag. Ex:
           action assigned-to="Vincent Massol, Steve Freeman" -->
  
      <category title="Code">

[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs changes.xml,1.2,1.3

[Vincent M. <vm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv20160/doc/xdocs

Modified Files:
	changes.xml 
Log Message:
source is packaged as a zip, not a jar ...

Index: changes.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/changes.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -d -r1.2 -r1.3
*** changes.xml	2001/08/15 14:23:02	1.2
--- changes.xml	2001/08/15 14:31:01	1.3
***************
*** 12,16 ****
    <release version="0.01 (release on August 12 2001">
      <action dev="SMGF" type="update">
!       The distribution zip now include a jar of the sources.
      </action>
      <action dev="VMA" type="update">
--- 12,16 ----
    <release version="0.01 (release on August 12 2001">
      <action dev="SMGF" type="update">
!       The distribution zip now includes a zip of the sources.
      </action>
      <action dev="VMA" type="update">

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

[Vincent M. <vm...@oc...>]

T10 - Remove the "java" and "doc" CVS modules on SF

----- Original Message -----
From: "Vincent Massol" <vm...@oc...>
To: <moc...@li...>
Sent: Wednesday, August 15, 2001 3:14 PM
Subject: [Mockobjects-java-dev] [Proposal] List of tasks for release 0.02


> 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] CVS: mockobjects-java/doc/xdocs changes.xml,1.1,1.2

[Vincent M. <vm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/doc/xdocs
In directory usw-pr-cvs1:/tmp/cvs-serv18233/doc/xdocs

Modified Files:
	changes.xml 
Log Message:
added changes I knew for release 0.01 but Steve need to fill with the other modifications he has made (mailing-list sample ?)

Index: changes.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/changes.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** changes.xml	2001/07/30 18:15:38	1.1
--- changes.xml	2001/08/15 14:23:02	1.2
***************
*** 7,13 ****
    <devs>
      <person name="Vincent Massol" email="vm...@us..." id="VMA"/>
    </devs>
  
!   <release version="0.1 in CVS">
      <action dev="VMA" type="update">
        Improved the build process and generate the user web site from XML files 
--- 7,17 ----
    <devs>
      <person name="Vincent Massol" email="vm...@us..." id="VMA"/>
+     <person name="Steve Freeman" email="sm...@us..." id="SMGF"/>
    </devs>
  
!   <release version="0.01 (release on August 12 2001">
!     <action dev="SMGF" type="update">
!       The distribution zip now include a jar of the sources.
!     </action>
      <action dev="VMA" type="update">
        Improved the build process and generate the user web site from XML files 

[Mockobjects-java-dev] CVS: mockobjects-java/lib .keepit,NONE,1.1

[Vincent M. <vm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/lib
In directory usw-pr-cvs1:/tmp/cvs-serv17375/lib

Added Files:
	.keepit 
Log Message:
file used to prevent CVS client pruning

--- NEW FILE: .keepit ---
This file is only there so that CVS clients will not prune this directory.
Why ? Because Ant will look for user jars in this diretory and if the directory
does not exist Ant will exit with an error (something "directory lib does
not exist" !).

[Mockobjects-java-dev] CVS: mockobjects-java build.xml,1.10,1.11

[Vincent M. <vm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java
In directory usw-pr-cvs1:/tmp/cvs-serv16796

Modified Files:
	build.xml 
Log Message:
prepare for version 0.02

Index: build.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/build.xml,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -d -r1.10 -r1.11
*** build.xml	2001/08/13 06:59:52	1.10
--- build.xml	2001/08/15 14:17:09	1.11
***************
*** 39,43 ****
      <!-- Generic project properties -->
      <property name="project.fullname" value="Mock Objects"/>
!     <property name="project.version" value="0.01"/>
      <property name="project.name" value="mockobjects"/>
  
--- 39,43 ----
      <!-- Generic project properties -->
      <property name="project.fullname" value="Mock Objects"/>
!     <property name="project.version" value="0.02"/>
      <property name="project.name" value="mockobjects"/>
  

[Mockobjects-java-dev] mailing list configuration

[Vincent M. <vm...@oc...>]

Is it possible to change the mailing list configuration so that it does not
prepend the name of the list to each message sent ? I find this a bit
annoying ...
Thanks
-Vincent

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

[Vincent M. <vm...@oc...>]

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] [IMPORTANT] Release Process

[Vincent M. <vm...@oc...>]

I went to the MockObjects web site .... and noticed that version 0.01 was
released ! <argh>

We'll consider this first release as a try .... and forget about it. Now I
would like use to agree on the release process. Can you review all the
following point and tell me whether you agree or not so that we can reach a
consensus. Once this is done we'll put a page on the web site explaining the
release process. Thanks

P1 - Releasing a version is a community action that we all need to decide
together (the committers of the project). Before *any* release, we will need
to agree on doing a release. This entails sending a message on the mailing
list asking for a vote on the release (I propose to use the Apache Jakarta
system for voting : http://jakarta.apache.org/site/decisions.html).

P2 - Long before any release, we need to define what will go into that
release, i.e. the list of tasks that need to be performed *prior* to that
release. These tasks will be listed in the
http://mockobjects.sourceforge.net/todo.html (todo.xml file in CVS). Tasks
can be proposed on the mailing list (such as the mail I sent on 1st of
august, entitled "[Proposal] Roadmap". Unfortunately noone answered so these
tasks were not entered in the todo page. I'm still waiting for an ageement
before entering them !).

P3 - The changes page (http://mockobjects.sourceforge.net/changes.html,
changes.xml file in CVS) need to be up to date at any time. The goal of this
page is not to described fine-grained changes in CVS like "I have corrected
a typo" but rather to advertise changes that are useful to end users (for
example: "Improved the Mailing-list example by ..."). As it is very hard to
remember everything that everyone has done, it is mandatory to fill this
page as we do the modifications and not to wait till the release to fill it.
At the current time, this page is *NOT* up to date.

P4 - Check list of administrative tasks to perform before any release :

A1 - Agree on a release (see P1)
A2 - Designate a release manager for the current release to perform
A3 - Ensure that no one is working on any part of the files (code freeze).
This is done by posting a mail on the list asking for a code freeze.
A4 - Verify that the todo.html files is up to date
A5 - Verify that the changes.html file is up to date
A6 - Verify that the features page is up to date and includes all features
available in all releases + the new ones of this release. Note: This page
does not currently exist but we should create it quickly. This is the page
that persons will look at the most often to see what features the Mock
Objects project has.
A7 - Verify that the news items on the index page are up to date (major
announcement should be listed there, a release is a major announcement - A
news item should be added that says which version has been released with a
link pointing to the changes page)
A8 - Perform a Ant build 'dist' on the release manager's machine to ensure
everything build fine including the tests, web site generation, ...
A9 - Tag CVS (with the name MO_0_01_RELEASE - example for release 0.01)
A10- Publish the distributables files to SF. In the release note area of SF,
put a link to the changes page
A11- Increase the version number indicated in the build.xml file by 1 (for
example, after 0.01, put 0.02)
A12- Write a release announcement in the news area of SF (with a link to the
changes page)
A13- Send a message to mockobjects-java-user and -dev mailing lists to
announce the availability of the release
A14- (optional) Send announcements to other mailing-lists (XP mailing lists
on yahoogroups, JUnit mailing list) and web sites (junit.org, objectmentor,
...)

... then relax ! ;-)

I propose that we start doing this immediatly and follow this process for
the 0.02 release.
Thanks
-Vincent



_______________________________________________
Mockobjects-java-users mailing list
Moc...@li...
http://lists.sourceforge.net/lists/listinfo/mockobjects-java-users