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

[Mockobjects-java-dev] RE: mockmaker conventions updated

[ivan m. <iv...@ta...>]

>That looks good, although I haven't tried it yet ... :)

:-(

>Here are a few comments to start with :
>* I think you should mention on http://mockmaker.sourceforge.net that the
>classes that are generated by Mock Maker are for the Mock Objects project
>and put a link to the project.

done on web site - will (further) clarify README on next release

>* You should put a changelog in the release notes area when you release a
>new version so that users know what to expect.
>
>Thanks
>-Vincent

I'll try to do release notes real soon

many thanks for your feedback,

Ivan





----------------------------------------------------------
This message was sent using                 http://uk2.net
NEWS - CHEAPEST DEDICATED SERVERS IN THE WORLD -  25/month
FREE UK DIAL 0845 609 1370 - username uk2: - password: uk2
UK's FREE Domains, FREE Dialup, FREE Webdesign, FREE email

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

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

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

Modified Files:
	todo.xml 
Log Message:
updated the todo list

Index: todo.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/todo.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- todo.xml	2001/08/15 15:22:28	1.5
+++ todo.xml	2001/08/21 14:47:02	1.6
@@ -8,9 +8,9 @@
       deliver a new version of the Mock Objects project. We need your help !
     </p>
     <p>
-      If you are interested in participating, send an email on the 
-      <link href="http://sourceforge.net/mail/?group_id=18189">Mock Objects 
-      mailing list</link> stating your interest and 
+      If you are interested in participating, send an email on the
+      <link href="http://sourceforge.net/mail/?group_id=18189">Mock Objects
+      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 persons that
@@ -30,10 +30,31 @@
          attribute to the action tag. Ex:
          action assigned-to="Vincent Massol, Steve Freeman" -->
 
-    <category title="Code">
+    <category title="Documentation">
+      <action assigned-to="Vincent Massol, Steve Freeman">
+        Write a page explaining the differences between Mock Objects and Stubs
+        as it is largely misunderstood.
+      </action>
+      <action>
+        Explain the code organisation in the src/ directory as wall as package
+        organisation.
+      </action>
       <action>
-        Clean up and merge the two directories 'vaj' and 'visualage' in
-        <code>src/extensions/com/mockobjects</code>.
+        Add a features page explaining current features of Mock Objects.
+      </action>
+    </category>
+    <category title="Code">
+      <action assigned-to="everyone">
+        Reformat all source code : Add javadoc to all code where needed +
+        add license + add version number + create packages.html and
+        overview.html + reformat according to coding conventions. We need to
+        do that ASAP.
+      </action>
+    </category>
+    <category title="Build">
+      <action assigned-to="Vincent Massol">
+        Finalise the build process (still need to finalise directory
+        structure + manage examples + manage extensions).
       </action>
     </category>
 

Re: [Mockobjects-java-dev] mockmaker conventions updated

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

Hi Ivan,

That looks good, although I haven't tried it yet ... :)
Here are a few comments to start with :
* I think you should mention on http://mockmaker.sourceforge.net that the
classes that are generated by Mock Maker are for the Mock Objects project
and put a link to the project.
* You should put a changelog in the release notes area when you release a
new version so that users know what to expect.

Thanks
-Vincent

----- Original Message -----
From: "ivan moore" <iv...@ta...>
To: <moc...@li...>
Sent: Monday, August 20, 2001 11:44 PM
Subject: [Mockobjects-java-dev] mockmaker conventions updated


> I have released a new version of MockMaker which
> tries to conform to the mockobjects method naming
> conventions in what it does.
>
> Formating and naming of the rest of the code
> that MockMaker produces and the source code
> for MockMaker will take a little longer to get changed ...
>
> please let me know what you think folks, and
> put any stories on the appropriate wiki page
> linked on the mockmaker homepage
>
> http://mockmaker.sourceforge.net
>
> Ivan Moore
>
>
>
>
> ----------------------------------------------------------
> This message was sent using                 http://uk2.net
> NEWS - CHEAPEST DEDICATED SERVERS IN THE WORLD -  25/month
> FREE UK DIAL 0845 609 1370 - username uk2: - password: uk2
> UK's FREE Domains, FREE Dialup, FREE Webdesign, FREE email
>
>
>
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> http://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>

[Mockobjects-java-dev] CVS: doc coding_conventions.html,1.1,NONE endotesting.html,1.1,NONE

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

Update of /cvsroot/mockobjects/doc
In directory usw-pr-cvs1:/tmp/cvs-serv511

Removed Files:
	coding_conventions.html endotesting.html 
Log Message:
removed docs that were moved to the mockobjects-java module

--- coding_conventions.html DELETED ---

--- endotesting.html DELETED ---

[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs release_process.xml,NONE,1.1 doc-book.xml,1.7,1.8 site-book.xml,1.7,1.8

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

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

Modified Files:
	doc-book.xml site-book.xml 
Added Files:
	release_process.xml 
Log Message:
new release process page that explains our release process

--- NEW FILE: release_process.xml ---
<?xml version="1.0"?>

<!DOCTYPE document SYSTEM "./dtd/document-v10.dtd">

<document>
  <header>
    <title>Release Process</title>
    <authors>
      <person name="Vincent Massol" email="vm...@us..."/>
    </authors>
  </header>

  <body>

  <s1 title="Introduction">

    <p>
      This document highlights our release process. It defines all the
      steps that need to be performed <strong>before</strong> releasing a new
      version of the Mock Objects project.
    </p>

  </s1>

  <s1 title="General steps">

    <s2 title="Decide on the content of a release">

      <p>
        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
        <strong>prior</strong> to that release. These tasks will be listed on
        the <link href="todo.html">Todo page</link>. Tasks can be proposed on
        the <link href="http://sourceforge.net/mail/?group_id=18189">mailing
        list</link>.
      </p>

    </s2>

    <s2 title="Deciding on doing a release">

      <p>
        Releasing a version is a community action that we all need to decide
        together (the committers of the project). Before <strong>any</strong>
        release, we will need to agree on doing a release. This entails sending
        a message on the
        <link href="http://sourceforge.net/mail/?group_id=18189">mailing
        list</link> asking for a vote on the release. We will use the
        <link href="http://jakarta.apache.org/site/decisions.html">Apache
        Jakarta system for voting</link>.
      </p>

    </s2>

    <s2 title="Updating the Changes page">

      <p>
        The <link href="changes.html">Changes page</link> 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.
      </p>

    </s2>

  </s1>

  <s1 title="Detailed administrative steps">

    <p>
      This is a detailed check list of all the steps involved to actually
      perform the release :
    </p>
    <ol>
      <li>
        Agree on a release (see above).
      </li>
      <li>
        Designate a release manager for the current release.
      </li>
      <li>
        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.
      </li>
      <li>
        Verify that the <link href="todo.html">todo.xml</link> page is up to
        date.
      </li>
      <li>
        Verify that the <link href="changes.html">changes.xml</link> page is up
        to date.
      </li>
      <li>
        Verify that the <link href="features.html">features.xml</link> page is
        up to date and includes all features available in all releases + the
        new ones from this release.
      </li>
      <li>
        Verify that the news items on the
        <link href="index.html">index.html</link> 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).
      </li>
      <li>
        Perform a Ant build on the dist target (<code>ant dist</code>) on the
        release manager's machine to ensure everything build fine including the
        tests, web site generation, ...
      </li>
      <li>
        Tag CVS, with the name MO_&lt;version number&gt;_RELEASE (For example,
        the 0.01 release would be tagged MO_0_01_RELEASE).
      </li>
      <li>
        Publish the distributables files to
        <link href="https://sourceforge.net/project/admin/editpackages.php?group_id=18189">
        SourceForge</link>. In the release notes area of SF, put a link to the
        Changes page (http://mockobjects.sf.net/changes.html).
      </li>
      <li>
        Increase the version number indicated in the <code>build.xml</code>
        file by 1 (for example, after 0.01, put 0.02).
      </li>
      <li>
        Write a short release announcement in the news area of SourceForge
        (with a link to the Changes page).
      </li>
      <li>
        Send a message to the dev and user mailing-lists of Mock Objects to
        announce the availability of the release (and add a link to the
        Changes page).
      </li>
      <li>
        Send announcements to other mailing-lists (XP mailing lists
        on yahoogroups, JUnit mailing list) and web sites (junit.org,
        objectmentor, ...)
      </li>
      <li>
        ... then relax ! ;-)
      </li>
    </ol>

  </s1>

  </body>
</document>

Index: doc-book.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/doc-book.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- doc-book.xml	2001/08/21 10:44:06	1.7
+++ doc-book.xml	2001/08/21 11:41:27	1.8
@@ -33,6 +33,7 @@
     <menu-item type="external" label="CVS"
         href="http://sourceforge.net/cvs/?group_id=18189"/>
     <menu-item label="Coding conventions" source="coding_conventions.xml"/>
+    <menu-item label="Release process" source="release_process.xml"/>
   </menu>
 
 </book>

Index: site-book.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/site-book.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- site-book.xml	2001/08/21 10:44:06	1.7
+++ site-book.xml	2001/08/21 11:41:27	1.8
@@ -33,6 +33,7 @@
     <menu-item type="external" label="CVS"
         href="http://sourceforge.net/cvs/?group_id=18189"/>
     <menu-item label="Coding conventions" source="coding_conventions.xml"/>
+    <menu-item label="Release process" source="release_process.xml"/>
   </menu>
 
 </book>

[Mockobjects-java-dev] JDBC Test First ?

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

Steve,

Any chance that we could put this paper in the Mock Objects web site ? Could
you put it in XML format ?

Thanks
-Vincent

[Mockobjects-java-dev] CVS: mockobjects-java build.xml,1.12,1.13

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

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

Modified Files:
	build.xml 
Log Message:
original endo testing paper (PDF) available as a link in endotesting.xml

Index: build.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/build.xml,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- build.xml	2001/08/20 16:21:09	1.12
+++ build.xml	2001/08/21 11:11:59	1.13
@@ -391,6 +391,13 @@
             <fileset dir="${xdoc.dir}/images"/>
         </copy>
 
+        <!-- Copy other files (non XML) -->
+        <copy todir="${out.doc.dir}">
+            <fileset dir="${xdoc.dir}">
+                <include name="misc/*.pdf"/>
+            </fileset>
+        </copy>
+
         <uptodate property="stylebook.doc.notrequired"
             targetfile="${out.doc.dir}/index.html">
 
@@ -445,6 +452,13 @@
         <!-- Copy the images -->
         <copy todir="${out.site.dir}/images">
             <fileset dir="${xdoc.dir}/images"/>
+        </copy>
+
+        <!-- Copy other files (non XML) -->
+        <copy todir="${out.site.dir}">
+            <fileset dir="${xdoc.dir}">
+                <include name="misc/*.pdf"/>
+            </fileset>
         </copy>
 
         <uptodate property="stylebook.site.notrequired"

[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs/misc mockobjects.pdf,NONE,1.1

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

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

Added Files:
	mockobjects.pdf 
Log Message:
original endo testing paper (PDF) available as a link in endotesting.xml

--- NEW FILE: mockobjects.pdf ---
%PDF-1.2 
%âãÏÓ
 
10 0 obj
<<
/Length 11 0 R
/Filter /LZWDecode 
>>
stream
€Š€ÑˆÈb.Œ„q¨Ð\5B 4` ‹ÅÎFq
,eK(àg$F$÷ÈÀl2›ß¦Cƃ(!ãÆSÁÐäa.
E‚™ÐÊv2ˆÇ#)”ÚaÇäHD"™Sc³(
&ÃIÀ@Cךc™LôÊp2õÇL”f0–
áQ{…ȍ
šI$Ñ;Ä°`4õ•/ú}vT3É0·Òø®!C"¢
¡s~ōÌhÜ xÄ7
pÆ7­›ì¢ÓÊ(m¸Ê 
¡˜á	
ápê5¶cƒ”ædDƒkê²%A’j"+ZÚ·¢2è»=‰SÜìËD–$R+N*9C˜@8.Àä©2pàÞnËl2
š:

Ì&7Ã+x7c+f.Mìƒ$aÊ"òG«Ê\´/’dÐO
8Ê,5Íór(CxÎ׍£jŠŽ8àŒ65ƒHÅH"°¡K2rŠû³‚†(r^ò³¨`j˜4aÈkS¢iÈP)ã0è;Œ-à@žê+z9Qa
€ðÙ¨°˜ÛòŒ­°Xû
U|÷
ÎqƒFß³OF„¯nî]Ûyw¦ü¢‡@ŸäLÉ]ö® ªÕéW+%l®•òÂßÃzSp-áì·ÇÖ¡MÂNAéø?#:
€7]å¤ðB¦ÀO !tæåþ=@öÞès\I02´
y9ƒi|§¤çœÏËÕ)†Ødžh2ðr)E›8 úÎ`fhf¿2H
A“4g‰Ù¡Ã\K
‘ÊÅ%HܛÇÊbÌvaVZŠ•PÈTHyS„©Æ}b*½Š$¥²£lØØ;ìr²ÒèŒø"€mwI{*†[+d9L87špI¥¡ŒɌ)䫲•……~±ódž‰i.±´Ó'àt Òͬ{ææ·ÚÿP¤wÌ`ä–0çYbe¨8øu=›ú«²æR*¸6-»ü b
.¹)†j7|ŒBof^0d‰éŽ:¦¦œžâ€SÔZýa»:¬ã’fi3lû4ðí&¸zÞîJNŠç-ZÀ-V~¦&¯Í:ÄÏæÓ=6DJzî›@Cy
ØãÝVnö%öÿ“1ÙM2g*[z!Hݹ«Jj@Ü8eb˜nÏoZ-¼¹Û"s:èÓe9XÖ¥UÕs}ÀaÕÂÆ˖ÍÎ76¡)½›¼—
»º!‘^Œê8®$Îe7‹óLG—ËìߘUÕÕnF
4Ó±ÝFÿøÕÂR
<+t½ú!Ð,@
ö÷snUtŒ«‚É9H1t[!ŽéšÏs}ÝÈ7—#c:nb6è
²Sq¥[qxG—µL¹pÚÀêÇÝJ“Ö‰ŸÕ
–K9.‰=Ú.Æèì*t—kÒ¥¦h§e$H4n7ø<¾|Tæ?D¿¼Ó"J2fµ÷œÞ~76E¶e5\Â~‡»CwÌ©¿>§6cގ
s).,D½b×ø},2Ø~Eí»í^Cá}Z€Ø—§‘‰gfè›û^âÊn~qmÞÅÌe«{"<©"ršwޖfÒïl¢Jó°
l”K\·KPñlðí,†‚æú¤`λkèªüÃíä*b‘¢H?/r’#,4ìPÅ@ÒōHyìRën|Š‹ÐÄPK Ø´(0­.¼)£xÊރ("ôԕ§ú秼'Àî1ìûÐ:ÍDl«¦0ˆR4ä&s®.ßEzç ÄûŒ,,¬1	)jËö± qæÀ§Ð\Iä¢LÊ(·@Ò¼âšu
Vτ0àÊl
µ#VÆŽ
c'#X­àÙçÁ	
`T¤Ú±¢ßšK«e ¥åäÃ!˾Äe&7ÐðÐ)J)«,ü§tKœƒl6ÏàSC¶KKº¸&Êj--–§8Î2;@Æíª†‡Ä¬sˆ!&-Èo¬1ïÒË6€+2oÈlyr†íN£œËC(lø·jL#ì¢  
endstream
endobj
11 0 obj
2892
endobj
4 0 obj
<<
/Type /Page
/Parent 5 0 R
/Resources <<
/Font <<
/F0 6 0 R 
/F1 7 0 R 
/F2 8 0 R 
/F3 9 0 R 
/F4 12 0 R 
>>
/ProcSet 2 0 R
>>
/Contents 10 0 R
>>
endobj
14 0 obj
<<
/Length 15 0 R
/Filter /LZWDecode 
>>
stream
€Š€Ñ¸È@7ÅÃq°€@T"FœLägEäaˆ€r.Á¡æ`h´`.†ÃXqPǐ
%rÓ¸€PE7
âÒ¡”æt4›Œã¡
TÜi:CçÔ
€ïH4	¦ó¬@O1Œ¦3¡ÌS5FC
 ¸h8FãAœ."#qÙ¶I‡ËïI¨ e_*XE¶;-žd
†’ÛŒšP6·Ë¦ÆFû:6˜h"¼ÈeÎN§9ð€æiψ¦c5nº.Íç- °@t4h3£vs= 6šLæŠI¸ßI2Œ»Ó)ààoÒm÷"
i„èu9O°˜´ceäq²q€Àj9–Þ¤/<Òlt7ˆ&Ãa¾jy7vÿ%'pÐ'î³@7+iðæ0ŽC˨پMº–;h’Ò±¤ÒòÏÒɇÒ¾ˆÐcš0£€Ø2¶Ïûä:·
˜æ
”§J@èå¿cxÙ¾
Pñ§.“t䌯¨à6¹n@Ü;
#Þ7Ir’͉"š.Rʼ°BNóÁ1Á‚Ö‘2I8b†“"ú+
#˜êùˆ#;@3A‚Td0¶Ò{@7ŒÊpÐ4ŒjŒåPx2Ä£dÎQC›H9¶¤ÿ
ñÓL4?#`È8ÊHïÆðl;Â" U¤
€p´/)„³U½ÁDoDÑc3ìôù
ŽÈÂ2ANlÚ®„ÜTåɒt¡$¶
80‹˜jÆcªŽÿ)pXäéM¡²8Ž²m$Ôµ<†L][3 ·Rø›ôÍ61×ÕÂ
n0îÞÖÃ
Û:՘àÿ>4ËBÞÐuiPß´rœ¨HM4I
âxsrÕ
€rÈCi8dð²Ï{s~7*«¤ëb7Ëí~Vñ…ýN8ìäb¡£#`$·³dÝ8NVä_BÍ­*‚1µKçbÑëµ.TØÈlöc©
CȆ3UՓ(\±Ö`®Ð|Ãä;
íD„èíãxō»4îɃ"‚Œ?6ÞWbÑ7¤ërMîô¤´ãhëEt.“ ÐBº„NéßB¦1Œ“#"z™!Á&ð؜Mó)È
´)´z–³¯;8Ÿ›¦·[~G§ü膗ڔC£ðrmd©@ÖáO!k%‹¬&ˆf»ÁAX+EqHx6TÙ4:5Ƚê›ÖαV¸i>mM”ópi¡J¡vÇ%ܟ¶"ðϒAˆ ÜÃP€¡i’ˆÆðŽ™A±ÀTŒQ™Ùa”4œ¥6’pmƒKmkˆ8ñ
@Ìž²)
3€æLÀ¦pîÒà2!D4½ž6¤
Hì4gšLÄ|‰1 B И™\s͌¯4¾¶sêͲZD ÅÉR䁘 .¤Œ’žCÂzZ±	E¤5êlʙŸ
ˆDÊRÉ)ÞQs—I’àdÔڈ4%*Ť!Z[)i€O&K`m.a 1!“¢=g½Ïò1),„X°ÃT|Hb05žâƒXs±ÍÊȸä .$[¹s.¤Õ<’Hµ¾
諌
¡æ ° J¨ag¨Eߐº
&•¢D¡±Õbæ$Þ‡„Ę´½
®Cù`‘…1Yˆk+‚ ¾$<é†gîê[<prPmnœÖÑ
"›‡aóE¬W‹GxoœØ2¶“Ã'Ú5_u‡DÏO‡$]<›|ò€PvTùH4µ9'ÜÜâ±Ù{¼î9¿£¢vh“žÓÊ	Üæk›×»ýÑê
û ˆþl
™?äN`<âÆ»é}v©$"ÐÉ¿Sê÷¿LšU֍¡é:Û©ü¦ ÀÔhߦ4u¥+ƒz}^®GHŸ 97‹×41j›â…Ãt@ˆƒÄ Dû½ù9ñV(õü¾ý·„±
¦%‡×Ö6ÚÙty,®È0ÓÆY¸¼KÞÃÚ·÷÷Ü@Ét²‡Ø6ùÏDãêÅ
>i^ð?DzmF، b;é:ª`f¦ebmèêQdT$z3E6X–èŽX4Ê[£6ñb­
Ç܊'âW
ú7®@du
ƒM
Å
endstream
endobj
15 0 obj
2797
endobj
13 0 obj
<<
/Type /Page
/Parent 5 0 R
/Resources <<
/Font <<
/F1 7 0 R 
/F2 8 0 R 
/F3 9 0 R 
>>
/ProcSet 2 0 R
>>
/Contents 14 0 R
>>
endobj
17 0 obj
<<
/Length 18 0 R
/Filter /LZWDecode 
>>
stream
€Š€Ñ¸È@7ÅÃq°€@T"FœLägEäaˆ€r.Á¡æ`h´`.†ÃXqPǐ
%rÓ¸€PE7
âÒ¡”æt4›Œã¡
TÜi:CçÔ
€ïH4	¦ó¬@O1Œ¦3¡ÌS5FC
 ¸h8FãAœ."#qÙ¶I‡ËïI¨ g_*XE¶;-ž)³Z."0Ð@1¶ŽdEI%û
a‡0ÛÝÆ7Èf²rAŒœn7”Í&Â¸4cec³¸Ìv‡%v’ÉÆ{­æ`1ïo“bq¾’j:ÏÄ󩊽`’Œ†"ènOŽÅÜñú=Ì£OŠ—oá>éæ 0ˆ•³Eâu2‹*UJµbµ\óš|çc)Èòc`Þ9Œ¯PÞ
oëø9A£šó‹b‚2?¬xs‹¡pA	'/è¸D8Ú0¨-j&µéވ--ÒÈ¥«Ò@-PP1ãpÆþÏ8Â1
㪒ä¨(Ä9AplôC*ˆ:

’æ9Ð
:
ð<¢92œ9)‹Õ(©2„9CxÌ֊TZ”!˜s¦”íBä8H¯BrDjé(êl¨óŒr¼³-Ë¡
6ÀjHÒ6ŽxåCÊHÈ4ŒÃ3ûNÇo=RTÒäÀ³uO%×°Ü'D
“òóÍA
‚?C~Ê G0ÓÌG8hͼ°d›¯Œµ äóŽösÖùCáf(L—ÔÄ,
æ©s¢Xß]m.á…^Ùc¨Î3©t¶9ùÝ´2ŒÃ
¹}P8v3¡@£7Ï)ƒ8º§H#dÃ(æ’ÕM²ôW”Ã)ÜHi‘ÜY5ɪ†¨eԐ4ñZú#o³PåzI¯Ì Œ¡hÎ9Qh@:¨óN¡j£Á0Ø*Œ›Öõòl©ªªº²­©=£äÑÚóF
áÜ724RóŒ[”7M“@µÞMšõo
í”…¢ÖZ’g!Á1)×B“Yªþu*!ö/ÜÏKE=E-¶¹3t
‚0s€C¸‡T➁±o7ò}ŸãM
=:¤¸â(p
Œm1"0Ü]!ËtNå+öœPc?Q¹:UdžAŒ^VÌÊ$Å®N[RT.Ù¿:Ç\—!BWŠ
˜ìÛ
BA8æ7l"RffQJ”’žʊ\Li”gд‘ÍI’E8¨$úêmÓ¹LG¦P”
ªñž³Ð¡£d“†K,澅"󏁴:†Ù
 D·†˜¤¾¥§€´Ûîf
ÝÞ¦7iŠKKu-ò,à0ŁPÒñÁá•+Ä%3„Ôr8_¥øaT‹"l„Œ$xòA	žî<lLJ 8D¥t”–›AZ×±(^✉/–Z=8Ð9J⛀”>?@™g¯Gòí@luîsФóIèi6ðóœ•ÜHilJiÖGÆè–”ϼÈëGÞ£ÿŒæûcI§¾,;V˜Ó”Ö>È0ëÐ:y;IE\–õz±ÖËY)I ©â¶Vç9Mj…7-Ֆt×Zn‰R2淄0Þ 
kñ9j6%Øû"Gͽ”­PîšSSÑ×s…ce…xy×üÈҗ—Oé;ÑÛÞ9v2üc`ðCú@§¦L”)( 
Ûz¼·ŸJ³)$Ý®Jã,¦sÜþ[êdÇM1
M©ÐÈyÖ¤I‰aà凖ØÓIüjhŠ=M0¿}Ãe»9a•!‡äO­6Š
òOêšOïÜ1ª×ùÅUbû¤P(sâÇ­¦³„þÐÔ~TUGxòèV
áŠ%†ÖÖhoÃêô³+º© h’&_Û4
°
ê/tˆæÆæÌæB§æîèði!‹2‘ l³€P¢Lì*Ë@é¦xÌrâöH Št/Š&"˜ûL”°Ïxûîy‡Vt.BÌêž,$â¤hëÃtºþ­ðh*/~T¼Oìb%Œ”…N¸m©Âª	ÆÔªv×ÊÒÕ)Ղþ:
ÄÖ
LÖJ´Ö‚ÌÖÂú×Â×JæÔÐÌڅ̤*…ƒˆ@â~ñ‡Ð±(Nœ-+$Ú*̲­~%
gR@®ËjT¯æþ̔_íÈËH„?åþ`%t¿DI®¢Zvº¤ºåð‰e.ð‰ÅK”yë˜5럊ÞþÄI*u©¾¸GŒì*ÞoˆNŠÐZìhÊc/
nvì`ŒD€Ø¸@¸
`²
`¨ šàŒ2¤
 ¤²zcZ¢  
endstream
endobj
18 0 obj
2877
endobj
16 0 obj
<<
/Type /Page
/Parent 5 0 R
/Resources <<
/Font <<
/F0 6 0 R 
/F1 7 0 R 
/F2 8 0 R 
/F4 12 0 R 
>>
/ProcSet 2 0 R
>>
/Contents 17 0 R
>>
endobj
20 0 obj
<<
/Length 21 0 R
/Filter /LZWDecode 
>>
stream
€Š€Ñ¸È@7ÅÃq°€@T"FœLägEäaˆ€r.Á¡æ`h´`.†ÃXqPǐ
%rÓ¸€PE7
âÒ¡”æt4›Œã¡
TÜi:CçÔ
€ïH4	¦ó¬@O1Œ¦3¡ÌS5FC
 ¸h8FãAœ."#qÙ¶I‡ËïI¨ i_*XE¶;-ž0´\.Dh0ÆOˆ»IqøkÌÚ6žH'°Òc0Ð
æáqFn­
†òà£3Sª”̧#¶Ì¸)à,11n8]‰ˆe²çC‘ä@{ÝJ‚®_/™ÍçsúNŒ]:)›Í¦S¡¢‚gÖí÷6W0QÎçŒ&“f´EÑÏh4Fá
Ïgµ9}Mó©°È
j=O`Ê2O’幡
sC3jƒ7B
ˆ7Ðð<óE5\‡ÎóR—
æþ´4°Í8Û#{ºÙƉ2QX²©:ÇV!ë퇍#5?Œ´2œ7ŽOõö£’}MŠŽôڟ7¸Þ3SÉý»6àC…ò:\Wås¿# ó‰M¸]þ6`#,ëE?÷=ÒdžÁÍZ˜!ÆUx¦Ö(Ӂa¶ ê¤Yª ëiX×8AyŽw­ï>¶xþC6»­
ŽüŒlõ‹HÙmé
‘šŽtد<jTˆÝ¿ù
™<ÏzÅHTúôyWeµ–í¼)*{»ÉÖúÿ§÷
´ÿÂJÚ­¤©<<6ŒC-r¯·Y~`JåMˆØ°Ê<65‘÷
8铥
°g—ÌZÕWè/¸¦ØBº«¤@*N}Ï»˜~JCOÿ‡9Ž”E~7CÊtîú7ÀÏ68Ž¥€5Œ®5¸ûZwÛúݨ:rÀØßµÃcLyÀ$xÊ=dªö3à€;õ”ÍBƒägñi¤¤J”Íé'Iè4ק´ÐÝÎà.>ÁÐ)冠ƒ,Væ´"P¬BEáH"„ˆPQäAˆøÌ$L²*;ˆq‰ÄT<P(¸‚`H’TGJž"'“4g‹ö4ð2B×æOÔb	oäÖÂR«	ÝW,1çFà×!JFI	(ñń› 2Qk	T%x–’àTp%ήÐ\Xäi|&Ì<'¢ªS¢CáCKܧõâZ¶«<7­žS™Þ5	µÑh›Šàu_OØ¨ 衟+W„]­˜¦¼
©,‘ÅŽ`«'„z†jÕo#xää±V–‰©ZÇ£Œö8wES!J»°äï_HyoGy	'ÒÃAIV.!ƼB^‚®LQ˜›Sèí_ô^ÉâV¹6,äÈt—Qù* \Ó
YÀÑ-–Ðr˜K¹(¡‹µYPdrA‰
¤½Ð¢&hu‹&T…C˜Kè £èŠ:bèe ´ˆÇ–4«šú°VAî1F2RÊñä0`âµ”wDÎ	¦4҉õEdy 92*‘I¨ý4euUVÍJ 1GD2«ª”–é^UM‰Wœú†M¨6(Â~rAh3!¦ôÐú®]+J©l¯EWØ2úÑë>¼¬š–:˜¡ô®‡Ôí'‚€vÓuh­¼Ù§òU
sŒÏ•¸±Â*Xa[† êߙBrʕ̪–¿[%·lÎ6|Lµl‘Ûõ¡
”&‡Fõ™ëÝ
ÅœW&êX£mRêT(ûVŠã#PîM"Ãæ›\ ey€À•ÏY0'¡®+,:÷@ÏÈa³LeNÝKÔónmd vÁ”»øQÅ$2\>^ô̙a±Õ3çÎW/7
1*þߊ8sNá‘M„YRљ£¹ŒÍKfæ­ãLûMQ¥^ÛÚÃÔ£ª)	´Ð;–DêÖìì‹2µ’;#›&žsÓo†kƒ‚&£5@ŒX Ó㷁]PvPÈÆVøRr²ù
xù]¦ü˨»JjڒŒÙ…s6ÄÎMs_@N^DÑ[¯l,\êãnBnEfÎïæ™ËeÓÇզÍôkS»lÜÄ]F8äYä·j²¾Ê<Ó,¶Iezf†yü>­dÚS>Æ3¡ï›1½Û™uOÇKcúžIðs-âÿ¦Ç™X›%l@ό¶iQ€´ÎiZº¥ú¾Ö|âjG‚zU¶1æ}ˆu…Ål4˅÷Ç0’¼G‰¸ÅxÁÅ7Ld¥YL¥jéC1ŸûR†cf®ÓõíÛàæâjT¶÷}ʺë&@ÀäÄÝVÚó5¬-z^	ù|ûQ:¨÷¿@oÂnA¼Ú§V}´¦˜kVÝî4§žâþ4oª|,9»º%éÁ­@ײªÿ¬íÞî7€0pÞ°&Ûñ>Úÿøj눱l—p‘¸ºÌŒ©Õ—#4ÛºT¢<(v;Qž&ØðRND»*"ï|"$‚D¾òƒF}¡’xt
Q™ðÊå¸tw0{Üé´OCÌP
‘Ii‚°WcŸ×2éFß³ áIÑz&u€Éö¾â.+ÿWð Ó/]wÚR×µZʀܚî'ÀDN£2ý¨œýïЊ`XøQ
¨ŠþҎ@¢  
endstream
endobj
21 0 obj
2370
endobj
19 0 obj
<<
/Type /Page
/Parent 5 0 R
/Resources <<
/Font <<
/F0 6 0 R 
/F1 7 0 R 
/F2 8 0 R 
/F4 12 0 R 
>>
/ProcSet 2 0 R
>>
/Contents 20 0 R
>>
endobj
23 0 obj
<<
/Length 24 0 R
/Filter /LZWDecode 
>>
stream
€Š€Ñ¸È@7ÅÃq°€@T"FœLägEäaˆ€r.Á¡æ`h´`.†ÃXqPǐ
%rÓ¸€PE7
âÒ¡”æt4›Œã¡
TÜi:CçÔ
€ïH4	¦ó¬@O1Œ¦3¡ÌS5FC
 ¸h8FãAœ."#qÙ¶I‡ËïI¨ k_*XE¶;-ž0´\.Dh0ÆOˆ»IqøkÌÚ—>à,11n8]‰ˆe²â‘”èu9„ÓÉJ|p7›ŽfR¼Èe恥AVˆA™°n÷¢Ž%i
EÒ-lh ºÈâRŒ¤ºmer÷C.Ç>÷qÄú%K¼¶^8³w&™mÐÄcnŠK|nŽI&êy—©
ã@ÊÕŠZ‚Œ)ã Ð7ŽªJ¦ªªêʶ®…
9WCà8
”`6×CpʚÈ*ìú'ŘßXXRsÖA͕FÞ¿@fÍ):ÇqÍÍ-:#b’ Ñª’¨«+
Ò¹#)È@9É
ÕaXƒHËTo
Ž·rYReX|l®IÒ0êٌ“èƒ#VýJLÉc+UM™ø›wdSˆÊô䀥ÈÃ8å(ŽqÍ5ޘš’§ƒe	&âø†4fc¨ÏÆ:š9)ýyßR|±nK–óƒR\/󟑤
Às­äáF
áZ…s¥6Ù
l8'ðíx/…Ô–œA
é5øÁ¤`¾‘t?nÍáò)uä%y]Wa‚"pʃHc
0¡PŠlc-
(P%0ÔƸA«Á{ Þ¥Dš c5
z'=HXê1Š\$&ˆ
é	6П£”ðÈgr1K棛=hMú^È ÆTUÈJIa…›y—C.SÄýò9ÃT¡S i¡儇J‰ê9“%Ov:*âl¥á°e“«
$°SVíKÒNv	é«©@ž-±U·$ù¶C¤aфµ^Ì2WHٓ˜f“(d|Wª‹Q±ÈäÄH"˜b
wZý´YkÐ]O¨–I8	 Ãb1j¨å”×{Y¬t©xj$Èt[â÷Œ«Á­Ú£.ƒ˜iá¹>„IwK
m.•Ìê?0;½"Xƒ‰lÁ¾9@õPˆ
ªb‰0|Ø(	¡®õ½I²nçÐÄöƬI
qÀ;¤`ځŸbpi,AB¿–°&` âª&®oLzr&!°*ôçòI¨Éi]f´&ԟ*»Ø²1¶=Ö¾Ð
ótA„˜ëÍxXFR­Lُ(uN’bíÖèjî­)&ÿÀt¨€l3ï¤1ƒ 1ã@Cƒ¨ D
	|6#\6€Q
Æô¨ò_€ÜG ¡
ۏ
ðdX)´‚¾jˆ$ã@. P4q˜À\yà
€Ýò6 \‘€è	Ȝ°éÑ7,Î7Ðc€å0ý‘-
ìY@‚‘‘>1BcÑ2ñKQQq*‰QY#L'©
endstream
endobj
24 0 obj
2659
endobj
22 0 obj
<<
/Type /Page
/Parent 5 0 R
/Resources <<
/Font <<
/F0 6 0 R 
/F1 7 0 R 
/F2 8 0 R 
/F3 9 0 R 
/F4 12 0 R 
>>
/ProcSet 2 0 R
>>
/Contents 23 0 R
>>
endobj
26 0 obj
<<
/Length 27 0 R
/Filter /LZWDecode 
>>
stream
€Š€Ñ¸È@7ÅÃq°€@T"FœLägEäaˆ€r.Á¡æ`h´`.†ÃXqPǐ
%rÓ¸€PE7
âÒ¡”æt4›Œã¡
TÜi:CçÔ
€ïH4	¦ó¬@O1Œ¦3¡ÌS5FC
 ¸h8FãAœ."#qÙ¶I‡ËïI¨ m_*XE¶;-ž0´\.Dh0ÆOˆ»IqøkÌØàu1
2ó±¼Òd`,0X¤¶â(8¨'B”äs7›ŠFS¼ät.
5ºýŽ†À
bºl¶»`no° Ü5ïNPÕŽ…}QÓ]Nê닕óފJ2ÄŸáv&!¥ÊÉ¥KäÚï†ž?ªÉæ½M8»Ãp»RՈƒ(è0#`æ܎îÈäí‡nóù¼i;Ìӏ®óÄ!rÞóµÃ4—Œc`Â9Žavã„ë~ñ<›Ü÷²ìË63¬ø@ÿºPÀíÓ¢éÁNí;Žð¨Eï{ßÈc“ýƒsr6"pÂ6Œ°d$T•&:Òtp:J2˜ò ŒòÈS·ò<“/L
tžÕÌ¡D¨ž ÐØÍSc—7K¯|+6˒P]CËiµåÂë(s
®+˜@º¤l’P¥IjôCʾˆ1(è4
1(Æ7Œƒ(@1+c|±­µUS£„ò<Øî2ŽÍs’¤Uum^ƒHÌ33c¨Ø¤Žƒx@ë'áB2Œ#pØ<Ø#Â:ŽuUF2ÂËHb²†4‚Ò“±ÏÂ`O2û4ÍtfïhPl´9ÌXgI¤B¢Hû
ª:ÊÝ
–ý5€Üå,!˜j·>”Š9~2/°s¥×XcŒ/²ÅGTàÊÐ(8b	‡¡·Ê7}җõ,\tÓè¾ÌqÔ	;Áª>yV'–ßìxl_x"@h˜@@6
öìJ ŒÍ°Ú0¨
èÂ1
㪓¬ŽY
rã@iʂŒ
ã5ž4\
ûÏ*Ðñܗ3ì´š0b„ß«êu©¨!p@$Éý¨295Ý¥jÈN°@0×6¨É<ë£z²­Ù–pä2ØÖÅGR؃Hæã­UV•Ø˅ñ‰ÿ/+ñiÏpî	͕┫ìCoÍ>›Díè¶å.%% "ICå™
ÔøÛ#lkóh/]ÕÆLã<Ð
tó›GÏz7	ó¯î§<ƒ·ök‰@¡ßG9
Ò¼³;J¿´µBMÿ— ƒ
i7'yG±l•B}AОSˆ^Éyö=…õ%zq ’ê/eõÿ'#¬žC‚{^0ß®˜þÂzOìåž0fA j.
,°¨Ð]
LSÃ_¯T0p
ْè°ý„EH‰Vèp!ɪæڊ	—).85éœXsQ¶P@åÚùÑ#0ø·HnA™ó,‡l½ÜDøÝú€Ð銘õÚ|Û±gµ.µ`@ꖠmoÁ]Y¸… [ÀÖ.7e{h¬etpc$ËëXTmªåT÷UìOE­*'ºR\0el®˜¨¨äëŒá¥^°µºÖÛ0vs¢XÀª\¸d}­ÆH€j
cڛ Þd0…Nœ¹\Zíú#* êQÖaK
E®­÷úN¼¤+¥9¬†Ã@·ØZ¬yH­ç@èrc›ÓŽ¯Z7;°Pg9K|o•ô¶3rúÑRŒ\HI÷¤¤¨Tʬü~i:[„YVåVKä'šaaaP<Ѐ×BŸý
¡åq‘À“rB=Mj%ø
U(û案
‡Jì!L!…` *P˜B€H	á:•'èjZPÄr1Tµ*>0]_LÔz$JŒhÙï¥ô&™åzjƒ0yŸô®vCß
•HQÎ͟Ƹ%%â²®Ù¨†Æ˜®Í
)b^=àˆ D
X ¢´^üé}¯í(·öÿß{óOiýA¨xüàZ3ZL\Õ0<݀\ýh˜(¿uîNä9G0´
~øՒ•0´…PŽžSêPª&BøJ‚Õ¬+WSˆT
õN˜^¥xÓ%P¸Úð#ü€œªû™¬u]]Ô9Z3,°¾åÚiæYÄÊÌp›MUºÙܺª«.Rå¨ÂåI±ê©T«Ö™Í
O“tx«¹2¸¨8dTVØÍÀÛ`åL!ÞaÈûpcÁ™)®'EOh¼€Xñ×a04†UX›DÐR`䐻+‘+ˆ©`‹ºr’jC|[6áæjX©¯`JZ%2ą́­Ëâ^zQ'ØI56XäÁ6L
ŽÅ·Ëªô§‹ùŒãEU¬æ–sL[A²*çiÇ"TLÒ&½Â•¬ëAªVÆm`T>TJè$ôÇmÙm‹á¼àŠ@È
endstream
endobj
27 0 obj
1975
endobj
25 0 obj
<<
/Type /Page
/Parent 5 0 R
/Resources <<
/Font <<
/F1 7 0 R 
/F2 8 0 R 
/F3 9 0 R 
>>
/ProcSet 2 0 R
>>
/Contents 26 0 R
>>
endobj
30 0 obj
<<
/Length 31 0 R
/Filter /LZWDecode 
>>
stream
€Š€Ñ¸È@7ÅÃq°€@T"FœLägEäaˆ€r.Á¡æ`h´`.†ÃXqPǐ
%rÓ¸€PE7
âÒ¡”æt4›Œã¡
TÜi:CçÔ
€ïH4	¦ó¬@O1Œ¦3¡ÌS5FC
 ¸h8FãAœ."#qÙ¶I‡ËïI¨ o_*XE¶;-ž)³Z."0Ð@1¶ŽdEK¼£y›apŒ(k½Ücq<€»%v‰Keð¡ ÆS4›3`шÄ\2´hq˜í.žG”Y:©†Ôk‡ßI&㡔äf0˜Ì¢!¤æc7¹Çžp.´`äùx†2铒I¥Q¸ß‰'Îûv‚¹ Ên§©Ç`È鎃@¤¿ãƒî2a
äë@3ã|,æŒcBŽ8Ž®œB9:Ž³°í?Jl(.kžèÀ|J4
㛧¾ÒÀß"«¡p@#
ã“f*KJN²N0øÓëæ2º*ˆÜ2¦£5:°Œ6;ºc»ôæÉ!F¤Dª\ÏŽ³T!*ʵ#D³0æ4£¬'JKãË
1±“¼ó†Áː—8¡ÅtùÖQ(‹ŒªLßQ©4<+ŒÃÞ6Ì
è@ûŽÃMœ7
¯¸èÚt*¤ªT3„ÁÉC@ò8M‰ô7ŒÊt¤ÁÕ´ôÚôۆUÚûŒ#`@ÿR#HÙE6Ðë~ƒË¨7ÎB/Œce;1AWl”
£
ƒÙLH¤S÷‰dA)øÂ1`N²|^QÈpOÕâNÂf+í!Œ/ÀÊ<ƒ“£x>Ö´Àæ9Ùýb7aó3þ3(.šÌ.s éa÷|ÎéŽcÊ~2ÚJ0
£€Ù®[XhݖÏa²×†!ÆÖä¦ÚŒÆéEøÿÔúýÙ3Í.³
Z	HŒ£” tú˜6<P#c]B90Éüù‡
q‘ÒBIP²'-Œ",V4˜\ˆ‹‚L ¸•*Ð|ª‰‡8.ù7ÓÁ±”3]DÐ\ŸØe–A´<„é“/AÚò”PÌSœƒº™aä Í S4fyšsPM`äŽkc	¡CͲ{:§dʛóJa‡Ùé(AtùšSÚ'£(ºi£Yæƒ&6ƒ–b½ß•>gÔûµu2O×#va¹G7`Ιã>+”9°0ÞSÊkr|±þ~–”m ÌYÉî7ž”÷"ٔ‘òD—Ò$É%à|¶‰q6MIÂO'¦”èZd-™dÙê.¨³Êp0g¦
ò¡$Í P˜j­Lžõ
©¤ô$gZ™@¢¤%Ò1:kñšn©UE$R(T
òÈ(%ÐèԚ­éŠµÎm?*tþ,¯ÎBze¬o¡®9“`¯RO>Îýb¨Óð2_–¯v.DHC jbly…7ôЅ•8g™
1´˜f€° iòr5@Tr®¢ˆtØéRKI¤@¥F>–XrÉb‰´£¦•¶TÓ°Ë+]s– ¢ÍËyv–'4½“@‚|§+
҇=¶6÷–Re”–4¾³Ë¢²÷,qX¾ÑÔWH+=±´e²IuœÙðmÀ6ùÆ[k]¡¹ÆZªSTR¾è%W”…–cQ¯1T邮9ï>hŒÿÄw\NOãçÁ†à3&hŒi20d½’ðP
Mœ‚°ìÒe3Q!Ïi¯ˆfÊ'£@\
¡Ô„7™zò’€fbÑŹÀù„ÅPRCxb«}!½tŒwWÎg}'ŽñÅj\Jbö8¯Í}f÷ʋ9aJ^<óøÿ“iÓ½á°;†´¥OÐs*ØÂ2,üRp
sBÜ6ˆ!°ÄZ¼©Ô!󝬐N©Õ`‚ÿ"3¢tƒƒ®’˜‡Þ䎂CºæDŒ®4~OÓ
ëÌ3ý^Žâk܅lŸ5†PÛ?Å%¤Ô-ÒãÊrÃl÷×P߈Þ##G†µNÔ]øܯ0«ÒJQ¹}BYÞՆT7}’Š:Á¯´
LIáìÌÄl¶ÃàGkf`dk	"F|@òNKÚoÄÒ@€ÒƘã'gL)$S®a,
KHWö捒cËPg¯ªµ‹ðÖ®‚¥àfâ¨àFЖ‘¥†™$Äj¤Nï|„§jL+2¶,{¤œì‡Xg%¦;C˜ Ä’§jk&¶
®c‡V‡˜çê¡
endstream
endobj
31 0 obj
2572
endobj
28 0 obj
<<
/Type /Page
/Parent 29 0 R
/Resources <<
/Font <<
/F0 6 0 R 
/F1 7 0 R 
/F2 8 0 R 
/F3 9 0 R 
/F4 12 0 R 
>>
/ProcSet 2 0 R
>>
/Contents 30 0 R
>>
endobj
33 0 obj
<<
/Length 34 0 R
/Filter /LZWDecode 
>>
stream
€Š€Ñ¸È@7ÅÃq°€@T"FœLägEäaˆ€r.Á¡æ`h´`.†ÃXqPǐ
%rÓ¸€PE7
âÒ¡”æt4›Œã¡
TÜi:CçÔ
€ïH4	¦ó¬@O1Œ¦3¡ÌS5FC
 ¸h8FãAœ."#qÙ¶I‡ËïI¨ q_*XE¶;-žd
†’ÛŒšP7Ú/3
ˆç#4›
QèÚa ˆfó&pèo§ÎF±t<Ði9ˆ*¤ûbc0›„,æŽ~l<ˆ7&A
ÌÞm2Ð9iÖ»Î̦“>oˆa3è
Óü†&-ÙF6ø…¦N0rRé€ÈcêÌ
3YÍá¸Êf¤
æa
 Â;((Ãæª:’:)c›Z$
îì2ŽAbœÍ·CxÜà8N+>6
Â9)/Ü26
#å¸/°Ê26-; î¢ Tó%
«Ò–¯I–!ëê~:ŒMãˆ7Ž£¤$©ªªº²­«¡a¹Ï¸ëÁУŽ#«835Lèß
ÿ).“úÿ³ƒ`˾ΠÌÚ
¡
²°­+ŒžÍ24œ7L‹KÃ3±‘ bÏ\r%O\}=(
Ä8àŽƒÈá„cr3Ž®Â}	D‘4>4§Ášç´¯Äêù#@ ŠM<ÝAÚØÄSô 3#“¾v•AR,ŒfÇ
ÀiM¡s	x/£|9ŽvKGP
H2ÒlE
ر= Ñ70%ò⎲µ­ÊãL²Ÿ5¢»£3ƒÅCQÍ@Ê<A	ÌaFƒ Ųss-”/‰°¬ØX#`‚3¾ŠØÃ(ߍ0Þ7ö ’§-ˆî9)
G‡ÛVãùoWÄ9ÂC»7Jh9È@+I’íí Úù×7=e^9bûŽC˜ÓìD%?ã
â3ãsƒg0ëÍ4ˆÅ"„sQ¦iÃ,$ύsò4Îã}ñã‘pç 'êDŠ2ÌwLÊÁœØ¸£lXb¶‡3bï"ˆmÁpr†¯}
qÄT%¬ÀÛB·…D7Ó$Zj@i¤à€3†”lNqЋf-@ÐRSñ¨nU,á”$…I³«¥’.Àlç@8À>ۆã[;ÐuZUm¢0ò¿**¹c•5OKöƒ
‘ö&­PÒ¶›jpì[€È
ì trO=ÿ§‹ÄÈÒ#âÕOʔŒ5d :

Q	ü¥("Ú[ãüƒíª”9
´Þ\ @Ŕ@o+í.b|/…,7õ5WXdŠQÉL=s:a!ÛQó¦¢ì4l gDðŽÔnš$Y®Õs bXW\Ì}L©º®ÇÒyaêyäÛ$3Š‰?^¢7Kìý´k¦SŒæ?3—
pš|eUálkˆ@ XË|Ž,?u¦VÃrí¨´<Y©†ÛÚøY!l&®œº,`ÀÖ¢kØv¬
+D™šñΐhÍZèžù„ qƒØMõjLÕá¸&R´aë°á[êhÛNjíõ8ˆÂ¯(—8ÔÒ㇢ïþC0¸¾äôJgÑÊ©ÅqÀIțЌ—Xý
j>®š
6ádÜáʌ…Þ^GĦç>x‡Ž¸u
{ÃÜ|#$çÈxt]ˆXÅe^]¬V/¬ÜlšÄeû).IÑL7B‚ÆòX&64Æ K´Ë¤º‚
OBrÀë¨
…ömDîDƒðY#Joàμ¢š@óàjß­¬ÊÂú6k°ùå%,Eú4¤ªOã8ê"¸°äü‹Ìº÷π8SQˎC3
#¥*‘=%`¦8㒸æ¡0|Mðƒ›"‰öSçäBÍÂ2΁g´µì
ÝQ4¥v'%¸Ñi#`F
endstream
endobj
34 0 obj
3019
endobj
32 0 obj
<<
/Type /Page
/Parent 29 0 R
/Resources <<
/Font 38 0 R
/ProcSet 2 0 R
>>
/Contents 33 0 R
>>
endobj
38 0 obj
<<
/F0 6 0 R
/F1 7 0 R
/F2 8 0 R
/F3 9 0 R
/F4 12 0 R
/F5 35 0 R
/F6 37 0 R
>>
endobj
40 0 obj
<<
/Length 41 0 R
/Filter /LZWDecode 
>>
stream
€Š€Ñ¸È@7ÅÃq°€@T"FœLägEäaˆ€r.Á¡æ`h´`.†ÃXqPǐ
%rÓ¸€PE7
âÒ¡”æt4›Œã¡
TÜi:CçÔ
€ïH4	¦ó¬@O1Œ¦3¡ÌS5FC
 ¸h8FãAœ."#qÙ¶I‡ËïI¨ s_*XE¶;-žd
†’ÛŒšQ‘K¦Èç#}2LÆcIŒêl¤›ÎBI´ào9œÍ&#a”@t7ˆFSÈÞd:˜Ì¢á
ìe7
º-v—Nr:MÇCaäY¯¥Ðcó¥F§U«Öku܆&-ÙF6ø…¦N1홀ÈeêšM¸ÛmùÌA:6˜h"ß\1!jŸ£ìé
ípÐ0·á•'Ž
hÂ9Œ£#^؍Ãz€Ý5òº’þ’ðÎ:§ÑLW†
¼nö<ñ|b‡¯£¸ÐØÊòÌ:9¶#
t8“Ò4¾Ðcj7Ȫ×Cs
EH!
ÒD.°ÁÀPCºJA¢kH<
q
p¸¨ûbÑ <nἶ×p_BØGgA…ÐhÆMê=i
fÑD´D
áØ\0GŽ>ºWZQq•¡¬]¶ÌUJ
e8%Œ2
)RH±Ì7[£ž¹]¯­Zp¯4ðŽPu(áÐ!›4 h–11/z½°ižH!í
1qDhõôKžÕ‚'†ø£G—ÛŠíÊH«k4¢bŒ‘š8‡pî™ò"7èh8:hÙƒH-E8†˜çãx?	E¤]Wèl“ܾ‹¡W“#"ä[¹—³ú@H$Á!

°VÅ]:ãQëÒlz&­ÕmS±-ÂÚF²˜ð…k¸ÉV?dÔW|”ƒM¢½I·CU4zíl¦³!ő‡rN†ÉdqµJzmKF¸Ó»ÂšÏTâ]5Êð×!ÖXaäjµë€;&ׁEúŒ±žÿ_üšåxoÀ¡Ê5Þíi
×AçÚ £«6ÂBBۇXÓýÁuw-r³O`(F݇¹ØýYÜû0.í!ùr	|µ¿¾‡Ma:å÷Y˜ÙÊ"?<ÏcÀCß\[÷›;]"îílÿ<Ó
Ê1PÀƒ±
"5ÿe¡£Â­œBHB	¨¤"2
endstream
endobj
41 0 obj
2335
endobj
39 0 obj
<<
/Type /Page
/Parent 29 0 R
/Resources <<
/Font <<
/F0 6 0 R 
/F1 7 0 R 
/F3 9 0 R 
/F4 12 0 R 
>>
/ProcSet 2 0 R
>>
/Contents 40 0 R
>>
endobj
6 0 obj
<<
/Type /Font
/Subtype /TrueType
/Name /F0
/BaseFont /Arial,Bold
/Encoding /WinAnsiEncoding
>>
endobj
7 0 obj
<<
/Type /Font
/Subtype /TrueType
/Name /F1
/BaseFont /TimesNewRoman
/Encoding /WinAnsiEncoding
>>
endobj
8 0 obj
<<
/Type /Font
/Subtype /TrueType
/Name /F2
/BaseFont /CourierNew
/Encoding /WinAnsiEncoding
>>
endobj
9 0 obj
<<
/Type /Font
/Subtype /TrueType
/Name /F3
/BaseFont /TimesNewRoman,Italic
/Encoding /WinAnsiEncoding
>>
endobj
12 0 obj
<<
/Type /Font
/Subtype /TrueType
/Name /F4
/BaseFont /TimesNewRoman,Bold
/Encoding /WinAnsiEncoding
>>
endobj
35 0 obj
<<
/Type /Font
/Subtype /TrueType
/Name /F5
/BaseFont /Symbol
/FirstChar 31
/LastChar 255
/Widths [ 600 250 333 713 500 549 833 778 439 333 333 500 549 250 549 250 
278 500 500 500 500 500 500 500 500 500 500 278 278 549 549 549 
444 549 722 667 722 612 611 763 603 722 333 631 722 686 889 722 
722 768 741 556 592 611 690 439 768 645 795 611 333 863 333 658 
500 500 631 549 549 494 439 521 411 603 329 603 549 549 576 521 
549 549 521 549 603 439 576 713 686 493 686 494 480 200 480 549 
600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 
600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 600 
600 600 620 247 549 167 713 500 753 753 753 753 1042 987 603 987 
603 400 549 411 549 549 713 494 460 549 549 549 549 1000 603 1000 
658 823 686 795 987 768 768 823 768 768 713 713 713 713 713 713 
713 768 713 790 790 890 823 549 250 713 603 603 1042 987 603 987 
603 494 329 790 790 786 713 384 384 384 384 384 384 494 494 494 
494 600 329 274 686 686 686 384 384 384 384 384 384 494 494 494 
600 ]
/FontDescriptor 36 0 R
>>
endobj
36 0 obj
<<
/Type /FontDescriptor
/FontName /Symbol
/Flags 6
/FontBBox [ -250 -220 1248 1000 ]
/MissingWidth 600
/StemV 109
/StemH 109
/ItalicAngle 0
/CapHeight 1000
/XHeight 700
/Ascent 1000
/Descent 220
/Leading 220
/MaxWidth 1040
/AvgWidth 600
>>
endobj
37 0 obj
<<
/Type /Font
/Subtype /TrueType
/Name /F6
/BaseFont /Arial
/Encoding /WinAnsiEncoding
>>
endobj
2 0 obj
[ /PDF /Text  ]
endobj
5 0 obj
<<
/Kids [4 0 R 13 0 R 16 0 R 19 0 R 22 0 R 25 0 R ]
/Count 6
/Type /Pages
/Parent 42 0 R
>>
endobj
29 0 obj
<<
/Kids [28 0 R 32 0 R 39 0 R ]
/Count 3
/Type /Pages
/Parent 42 0 R
>>
endobj
42 0 obj
<<
/Kids [5 0 R 29 0 R ]
/Count 9
/Type /Pages
/MediaBox [ 0 0 595 842 ]
>>
endobj
1 0 obj
<<
/Creator (Microsoft Word )
/CreationDate (20 July 2000 12:16:00 am)
/Title (Endo-Testing: Unit Testing with Mock Objects)
/Author (Mackinnon, Freeman, Craig)
/Producer (Acrobat PDFWriter 3.02 for Windows)
/Keywords (XP, Unit Testing, Mock Objects, Stubs)
/Subject ()
>>
endobj
3 0 obj
<<
/Pages 42 0 R
/Type /Catalog
/DefaultGray 43 0 R
/DefaultRGB  44 0 R
>>
endobj
43 0 obj
[/CalGray
<<
/WhitePoint [0.9643 1 0.8251 ]
/Gamma 2.2003 
>>
]
endobj
44 0 obj
[/CalRGB
<<
/WhitePoint [0.9643 1 0.8251 ]
/Gamma [2.2003 2.2003 2.2003 ]
/Matrix [0.5347 0.2919 0.0252 0.3 0.653 0.1177 0.129 0.055 0.6812 ]
>>
]
endobj
xref
0 45
0000000000 65535 f
0000028537 00000 n
0000028190 00000 n
0000028836 00000 n
0000003021 00000 n
0000028224 00000 n
0000026088 00000 n
0000026208 00000 n
0000026331 00000 n
0000026451 00000 n
0000000021 00000 n
0000002997 00000 n
0000026581 00000 n
0000006107 00000 n
0000003202 00000 n
0000006083 00000 n
0000009249 00000 n
0000006264 00000 n
0000009225 00000 n
0000011897 00000 n
0000009419 00000 n
0000011873 00000 n
0000014834 00000 n
0000012067 00000 n
0000014810 00000 n
0000017099 00000 n
0000015016 00000 n
0000017075 00000 n
0000019936 00000 n
0000028340 00000 n
0000017256 00000 n
0000019912 00000 n
0000023246 00000 n
0000020119 00000 n
0000023222 00000 n
0000026710 00000 n
0000027798 00000 n
0000028074 00000 n
0000023368 00000 n
0000025917 00000 n
0000023474 00000 n
0000025893 00000 n
0000028437 00000 n
0000028934 00000 n
0000029022 00000 n
trailer
<<
/Size 45
/Root 3 0 R
/Info 1 0 R
/ID [<67e5a53a76546d4dff1da18bcc6f9498><67e5a53a76546d4dff1da18bcc6f9498>]
>>
startxref
29194
%%EOF
ld
/Encoding /WinAnsiEncoding
>>
endobj
7 0 obj
<<
/Type /Font
/Subtype /TrueType
/Name /F1
/BaseFont /TimesNewRoman
/Encoding /WinAnsiEncoding
>>
endobj
8 0 obj
<<
/Type /Font
/Subtype /TrueType
/Name /F2
/BaseFont /CourierNew
/Encoding /WinAnsiEncoding
>>
endobj
9 0 obj
<<
/Type /Font
/Subtype /TrueType
/Name /F3
/BaseFont /TimesNewRoman,Italic
/Encoding /WinAnsiEncoding
>>
endobj
12 0 obj
<<
/Type /Font
/Subtype /TrueTy

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

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

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

Modified Files:
	endotesting.xml 
Log Message:
original endo testing paper (PDF) available as a link in endotesting.xml

Index: endotesting.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/endotesting.xml,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- endotesting.xml	2001/08/05 20:13:19	1.1
+++ endotesting.xml	2001/08/21 11:11:43	1.2
@@ -17,10 +17,11 @@
     <s1 title="Endo-Testing: Unit Testing with Mock Objects">
 
       <note>
-        This paper was presented at the conference, "eXtreme Programming and 
+        This paper was presented at the conference, "eXtreme Programming and
         Flexible Processes in Software Engineering - XP2000". <br/>
         (c) 2000 Tim Mackinnon, Steve Freeman, Philip Craig. To be published in
-        <em>XP eXamined</em> by Addison-Wesley.
+        <em>XP eXamined</em> by Addison-Wesley. The original paper is
+        available <link href="misc/mockobjects.pdf">here</link> (PDF format).
       </note>
 
       <p>
@@ -124,7 +125,7 @@
           validate the inputs they have received from our unit test. In the
           following example, <code>JUnitCreatorModel</code> is an object that
           generates test classes in the VisualAge workspace, and
-          <code>myMockPackage</code> and <code>myMockWorkspace</code> are Mock 
+          <code>myMockPackage</code> and <code>myMockWorkspace</code> are Mock
           Object implementations of interfaces provided with VisualAge:
         </p>
 
@@ -134,7 +135,7 @@
       new MockType(EXISTING_CLASS_NAME));
     myMockWorkspace.addPackage(mockPackage);
 
-    JUnitCreatorModel creatorModel = 
+    JUnitCreatorModel creatorModel =
       new JunitCreatorModel(myMockWorkspace, PACKAGE_NAME);
 
     try {
@@ -148,21 +149,21 @@
 ]]></source>
 
         <p>
-          There are two important points to note here. First, this test 
-          does not test VisualAge, it only tests one piece of code that we have 
-          written or, with test-driven programming, are about to write. The 
-          full behaviour is exercised during functional testing. Second, we 
-          are not trying to rewrite VisualAge, only to reproduce those 
-          responses that we need for a particular test. Most of the methods of 
-          a mock implementation do nothing or just store values in local 
-          collections. For example, the implementation of the class 
+          There are two important points to note here. First, this test
+          does not test VisualAge, it only tests one piece of code that we have
+          written or, with test-driven programming, are about to write. The
+          full behaviour is exercised during functional testing. Second, we
+          are not trying to rewrite VisualAge, only to reproduce those
+          responses that we need for a particular test. Most of the methods of
+          a mock implementation do nothing or just store values in local
+          collections. For example, the implementation of the class
           <code>MockPackage</code> might include:
         </p>
 
 <source><![CDATA[
   public class MockPackage implements Package {
     private Vector myContainedTypes = new Vector();
-    ... 
+    ...
     public void addContainedType(Type type) {
       myContainedTypes.add(type);
     }
@@ -216,7 +217,7 @@
         </p>
 
       </s2>
-    
+
       <s2 title="Why use Mock Objects ?">
 
         <s3 title="Localising Unit Tests">
@@ -236,7 +237,7 @@
             </p>
 
             <p>
-              For example, we might have a method on a class 
+              For example, we might have a method on a class
               <code>Employee</code> that updates names and details atomically :
             </p>
 
@@ -280,8 +281,8 @@
 ]]></source>
 
             <p>
-              This technique is very easy to implement in modern development 
-              environments, especially given industry standard interfaces such 
+              This technique is very easy to implement in modern development
+              environments, especially given industry standard interfaces such
               as JDBC.
             </p>
 
@@ -294,8 +295,8 @@
               single piece of functionality. A unit test that depends on complex
               system state can be difficult to set up, especially as the rest of
               the system develops.  Mock Objects avoid such problems by
-              providing a lightweight emulation of the required system state. 
-              Furthermore, the setup of complex state is localised to one 
+              providing a lightweight emulation of the required system state.
+              Furthermore, the setup of complex state is localised to one
               Mock Object instead of scattered throughout many unit tests.
             </p>
 
@@ -303,9 +304,9 @@
               One of the authors of this chapter worked on a project tool that
               released code from VisualAge to another source control system. As
               the tool grew, it became increasingly hard to unit test because
-              the cost of resetting the environment rose dramatically. The 
+              the cost of resetting the environment rose dramatically. The
               project tool was later refactored to use mock implementations of
-              both VisualAge and the source control system.  The result was 
+              both VisualAge and the source control system.  The result was
               both easier to test and better structured.
             </p>
 
@@ -315,10 +316,10 @@
 
             <p>
               Some unit tests need to test conditions that are very difficult to
-              reproduce. For example, to test server failures we can write a 
-              Mock Object that implements the local proxy for the server. Each 
-              unit test can then configure the proxy to fail with an expected 
-              problem and the developers can write client code to make the test 
+              reproduce. For example, to test server failures we can write a
+              Mock Object that implements the local proxy for the server. Each
+              unit test can then configure the proxy to fail with an expected
+              problem and the developers can write client code to make the test
               pass. An example of this is
             </p>
 
@@ -341,17 +342,17 @@
             <p>
               With this approach, the mock server runs locally and fails in a
               controlled manner. The test has no dependencies on components
-              outside the development system and is insulated from other 
-              possible real world failures.  This style of test is repeated 
-              for other types of failure, and the entire test suite documents 
+              outside the development system and is insulated from other
+              possible real world failures.  This style of test is repeated
+              for other types of failure, and the entire test suite documents
               the possible server failures that our client code can handle.
             </p>
 
             <p>
               In the case of an expensive widget, we define similar unit
               tests. We can configure the mock widget with the desired state and
-              check that it has been used correctly. For example, a unit test 
-              that checks that the widget is polled exactly once when a 
+              check that it has been used correctly. For example, a unit test
+              that checks that the widget is polled exactly once when a
               registration key is sent would be
             </p>
 
@@ -383,24 +384,24 @@
 
             <p>
               Domain objects often fail some time after an error occurs, which
-              is one reason that debugging can be so difficult. With tests that 
-              query the state of a domain object, all the assertions are made 
-              together after the domain code has executed. This makes it 
-              difficult to isolate the exact point at which a failure occurred. 
-              One of the authors of this chapter experienced such problems 
-              during the development of a financial pricing library. The unit 
-              tests compared sets of results after each calculation had 
-              finished. Each failure required considerable tracing to isolate 
-              its cause, and it was difficult to test for intermediate values 
+              is one reason that debugging can be so difficult. With tests that
+              query the state of a domain object, all the assertions are made
+              together after the domain code has executed. This makes it
+              difficult to isolate the exact point at which a failure occurred.
+              One of the authors of this chapter experienced such problems
+              during the development of a financial pricing library. The unit
+              tests compared sets of results after each calculation had
+              finished. Each failure required considerable tracing to isolate
+              its cause, and it was difficult to test for intermediate values
               without breaking encapsulation.
             </p>
 
             <p>
               On the other hand, a mock implementation can test assertions each
               time it interacts with domain code, and so is more likely to fail
-              at the right time and generate a useful message. This makes it 
-              easy to trace the specific cause of the failure, especially as 
-              the failure message can also describe the difference between the 
+              at the right time and generate a useful message. This makes it
+              easy to trace the specific cause of the failure, especially as
+              the failure message can also describe the difference between the
               expected and actual values.
             </p>
 
@@ -431,13 +432,13 @@
             <p>
               Without Mock Objects, each unit test tends to have its own set of
               assertions about the domain code. These may be refactored into
-              shared methods within a unit test, but the developer has to 
-              remember to apply them to new tests.  Such assertions are built 
-              into Mock Objects and so are applied by default whenever the 
-              object is used. As the suite of unit tests grows, a Mock Object 
-              will be used throughout the system and its assertions applied to 
-              new code. Similarly, as the developers discover new assertions 
-              that need to be made, these can be added once in a Mock Object 
+              shared methods within a unit test, but the developer has to
+              remember to apply them to new tests.  Such assertions are built
+              into Mock Objects and so are applied by default whenever the
+              object is used. As the suite of unit tests grows, a Mock Object
+              will be used throughout the system and its assertions applied to
+              new code. Similarly, as the developers discover new assertions
+              that need to be made, these can be added once in a Mock Object
               where they will automatically apply to all existing tests.
             </p>
 
@@ -446,14 +447,14 @@
               assertions in their Mock Objects have failed unexpectedly. Usually
               this is a timely warning about a constraint that the programmers
               have forgotten, but sometimes this is because the failing
-              constraints are not always relevant.  These cases suggest 
-              candidates for refactoring of either the domain code or Mock 
-              Objects, and help to push the developers toward a better 
+              constraints are not always relevant.  These cases suggest
+              candidates for refactoring of either the domain code or Mock
+              Objects, and help to push the developers toward a better
               understanding of the system.
             </p>
 
           </s4>
-          
+
         </s3>
 
         <s3 title="Effects on Coding Style">
@@ -559,9 +560,9 @@
           </p>
 
           <p>
-            Instead, we can write a handler object to reify this 
-            dialogue between a writer and a <code>Person</code>. 
-            <code>Person</code> would then have a method to pass its internal 
+            Instead, we can write a handler object to reify this
+            dialogue between a writer and a <code>Person</code>.
+            <code>Person</code> would then have a method to pass its internal
             contents to a handler :
           </p>
 
@@ -581,13 +582,13 @@
           </p>
 
 <source><![CDATA[
-  void testPersonHandling() { 
+  void testPersonHandling() {
     myMockHandler.setExpectedName(NAME);
     myMockHandler.setExpectedAge(AGE);
     myMockHandler.setExpectedTelephone(TELEPHONE);
-  
+
     myPerson.handleDetails(myMockHandler);
-  
+
     myMockHandler.verify();
   }
 ]]></source>
@@ -602,13 +603,13 @@
   void testPersonPrintHandler() {
     myMockPrintWriter.setExpectedOutputPattern(
       ".*" + NAME + ".*" + AGE + ".*" + TELEPHONE + ".*");
-  
+
     myPrintHandler.name(NAME);
     myPrintHandler.age(AGE);
     myPrintHandler.telephone(TELEPHONE);
-  
+
     myPrintHandler.writeTo(myMockPrintWriter);
-  
+
     myMockPrintWriter.verify();
   }
 ]]></source>
@@ -678,7 +679,7 @@
 ]]></source>
 
           <p>
-            would then return to the <code>Person</code> class and adjust any 
+            would then return to the <code>Person</code> class and adjust any
             method signatures to use the new interface :
           </p>
 
@@ -690,7 +691,7 @@
 
           <p>
             This approach ensures that the interface will be the minimum that
-            the domain code needs, following the Extreme Programming principle 
+            the domain code needs, following the Extreme Programming principle
             of not adding features beyond our current understanding.
           </p>
 
@@ -804,7 +805,7 @@
 
 <source><![CDATA[
   public class ExpectationList implements Verifiable {
-    public ExpectationList(String failureMessage); 
+    public ExpectationList(String failureMessage);
     public void addExpected(Object expectedItem);
     public void addActual(Object actualItem);
     public void verify() throws AssertionFailedException;
@@ -846,36 +847,36 @@
 
       <s2 title="References">
 
-        <p>      
-          [Beck2000] K. Beck. <em>Extreme Programming.</em>Addison-Wesley, 
+        <p>
+          [Beck2000] K. Beck. <em>Extreme Programming.</em>Addison-Wesley,
           2000.<br/>
           [Binder2000] R. V. Binder. <em>Testing Object-Oriented Systems :
           Models, Patterns, and Tools</em>. Addison-Wesley, 2000.<br/>
-          [C2] Various Authors. <em>SingletonsAreEvil.</em> On-line at 
+          [C2] Various Authors. <em>SingletonsAreEvil.</em> On-line at
           <link href="http://c2.com/cgi/wiki?SingletonsAreEvil">
           http://c2.com/cgi/wiki?SingletonsAreEvil</link><br/>
-          [Gamma+1995] R. Gamma, R. Helm, R. Johnson, J. Vlissides. 
-          <em>Design Patterns: Elements of Reusable Object-Oriented 
+          [Gamma+1995] R. Gamma, R. Helm, R. Johnson, J. Vlissides.
+          <em>Design Patterns: Elements of Reusable Object-Oriented
           Software</em>. Addison-Wesley, 1995.<br/>
-          [Lieberherr+1989] K. J. Lieberherr, I. M. Holland. "Assuring 
-          Good Style for Object-Oriented Programs." <em>IEEE Software</em> 
+          [Lieberherr+1989] K. J. Lieberherr, I. M. Holland. "Assuring
+          Good Style for Object-Oriented Programs." <em>IEEE Software</em>
           Volume 6, Number 5, pp. 38-49, September 1989.<br/>
-          [Mackinnon2000] T. Mackinnon. <em>JunitCreator</em>. On-line at 
+          [Mackinnon2000] T. Mackinnon. <em>JunitCreator</em>. On-line at
           <link href="http://www.xpdeveloper.com/cgi-bin/wiki.cgi?JunitCreator">
           http://www.xpdeveloper.com/cgi-bin/wiki.cgi?JunitCreator</link>.<br/>
-          [Stroustrup1994] B. Stroustrup. <em>The Design and Evolution of 
+          [Stroustrup1994] B. Stroustrup. <em>The Design and Evolution of
           C++</em>. Addison-Wesley, 1994.<br/>
         </p>
-        
+
       </s2>
 
       <s2 title="Acknowledgments">
-        
+
         <p>
-          We would like to thank the reviewers and the following colleagues 
-          for their contributions to this chapter: Tom Ayerst, Oliver Bye, 
-          Richard Karcich, Matthew Cooke, Sven Howarth, Tung Mac, Peter Marks, 
-          Ivan Moore, John Nolan, Keith Ray, Paul Simmons, and J. D. 
+          We would like to thank the reviewers and the following colleagues
+          for their contributions to this chapter: Tom Ayerst, Oliver Bye,
+          Richard Karcich, Matthew Cooke, Sven Howarth, Tung Mac, Peter Marks,
+          Ivan Moore, John Nolan, Keith Ray, Paul Simmons, and J. D.
           Weatherspoon.
         </p>
 

[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs/misc - New directory

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

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

Log Message:
Directory /cvsroot/mockobjects/mockobjects-java/doc/xdocs/misc added to the repository

[Mockobjects-java-dev] www.mockobjects still not pointing to SF

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

The http://www.mockobjects.com domain is still not pointing to
http://mockobjects.sourceforge.com ... Could we change that quickly ?

Thanks
-Vincent

[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs coding_conventions.xml,1.2,1.3 doc-book.xml,1.6,1.7 site-book.xml,1.6,1.7

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

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

Modified Files:
	doc-book.xml site-book.xml 
Added Files:
	coding_conventions.xml 
Log Message:
first try for coding conventions. The idea is to get feedback from other Mock Objects developers and find an agreement on coding conventions. I propose this document as a start. Let's modify it to suit our needs. Bear in mind that it lives in CVS only and is not published on the public web site yet ...


Index: doc-book.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/doc-book.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- doc-book.xml	2001/08/21 10:35:10	1.6
+++ doc-book.xml	2001/08/21 10:44:06	1.7
@@ -32,6 +32,7 @@
   <menu label="Developers">
     <menu-item type="external" label="CVS"
         href="http://sourceforge.net/cvs/?group_id=18189"/>
+    <menu-item label="Coding conventions" source="coding_conventions.xml"/>
   </menu>
 
 </book>

Index: site-book.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/site-book.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- site-book.xml	2001/08/21 10:35:10	1.6
+++ site-book.xml	2001/08/21 10:44:06	1.7
@@ -32,6 +32,7 @@
   <menu label="Developers">
     <menu-item type="external" label="CVS"
         href="http://sourceforge.net/cvs/?group_id=18189"/>
+    <menu-item label="Coding conventions" source="coding_conventions.xml"/>
   </menu>
 
 </book>

[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs naming_conventions.xml,NONE,1.1

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

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

Added Files:
	naming_conventions.xml 
Log Message:
renamed "coding conventions" into "naming conventions" as this is what they are. Will add coding conventions which will be the coding conventions used internally by the Mock Objects project on its code (this will be for developers only, not for end users, whereas the naming conventions are useful to end users).

--- NEW FILE: naming_conventions.xml ---
<?xml version="1.0"?>

<!DOCTYPE document SYSTEM "./dtd/document-v10.dtd">

<document>
  <header>
    <title>Mock Object Naming Conventions</title>
  </header>

  <body>

    <s1 title="Mock Object Naming Conventions">

      <p>
        Over time we have developed some naming conventions for how we write
        mock objects which we believe make them easier to work with.
      </p>

      <s2 title="Creating expectations">

        <p>
          We have built up a library of expectation classes to help with the 
          development of mock objects. Each expectation object will compare 
          pre-loaded expected values with actual values as they arrive. Where 
          possible, the comparison will be made as the actual object is set, 
          which helps to locate errors when they occur. Each expectation class 
          has a constructor that takes a name value. This name will be 
          displayed when an assertion fails, so it should help to identify the
          source of any error. For example, the instance variables for the mock
          sql statement include:
        </p>

<source><![CDATA[
  protected ExpectationCounter myCloseCalls = 
        new ExpectationCounter("MockStatement.closeCalls");
  protected ExpectationCounter myExecuteCalls = 
        new ExpectationCounter("MockStatement.executeCalls");
  protected ExpectationValue myQueryString = 
        new ExpectationValue("MockStatement.queryString");
]]></source>

        <p>
          Note that the variables have the name of the thing they test,
          <code>myQueryString</code> rather than
          <code>myExpectedQueryString</code>. This is to avoid repetitions 
          such as :
        </p>

<source><![CDATA[
  myExpectedQueryString.setExpected(aString);
]]></source>

      </s2>

      <s2 title="Setting expectations">

        <p>
          All expectations are set with a method beginning
          <code>setExpected&lt;condition&gt;,</code> where
          <code>&lt;condition&gt;</code> is a state or behaviour that will be 
          verified during or at the end of the test. For example,
        </p>

<source><![CDATA[
  myMockHttpResponse.setExpectedContentType("text/plain");
]]></source>

        <p>
          says that the <code>HttpResponse</code> expects to have its content 
          type set to <code>&quot;text/plain&quot;</code> during the test.
        </p>
    
        <p>
          If an expectation that a mock object supports is not set, then it 
          will not be verified, this makes it easier to use a mock object for 
          multiple tests. To check that a value is not changed during a test, 
          each Expectation type supports the method
          <code>setExpectNothing</code>. For example, to test that no properties 
          of a bean have been set its mock implementation might include the 
          method :
        </p>

<source><![CDATA[
  public void setExpectNoPropertiesSet() {
    myProperties.setExpectNothing();
  }
]]></source>

        <p>
          The expectation collections include methods for adding single objects 
          and collections of objects. This is to allow clients to set an 
          expectation that is itself a collection object, perhaps to check the 
          identity of an array, rather than its contents. When using a 
          collection expectation in a mock object please be clear in your 
          expectations whether you are adding to or overriding the current 
          expected values. For example, the method :
        </p>

<source><![CDATA[
  public void addExpectedProperty(String property) {
    myProperties.addExpected(property);
  }
]]></source>

        <p>
          adds an additional property that the mock object will expect to 
          receive. The method :
        </p>

<source><![CDATA[
  public void setExpectedProperty(String property) {
    myProperties.setExpectNothing();
    myProperties.addExpected(property);
  }
]]></source>

        <p>
          resets the property expectation.
        </p>

      </s2>

      <s2 title="Setting actual values">

        <p>
          The actual values for comparison against the expected values will be 
          set in the mock implementations of real methods. For example, we 
          count the number of times <code>close</code> is called in a mock sql 
          statement in the method :
        </p>

<source><![CDATA[
  public void close() throws SQLException {
    myCloseCalls.inc();
  }
]]></source>

        <p>
          similarly, to set a positional parameter in a mock prepared 
          statement :
        </p>

<source><![CDATA[
  public void setObject(int param, Object obj) throws SQLException {
    mySetParameters.addActual(new MapEntry(new Integer(param), obj));
  }
]]></source>

      </s2>

      <s2 title="Setting stub values">

        <p>
          Many mock objects are used for both validation of expectations and 
          as stub implementations to allow tests to run without external 
          dependencies. For example, we often need to set parameters values in 
          a mock servlet request for the target code to retrieve; these 
          properties values are not verified because we are testing how they 
          are used, not how they are set. The setter method is :
        </p>

<source><![CDATA[
  public void setupAddParameter(String paramName, String value) {
    setupAddParameter(paramName, new String[] { value });
  }
]]></source>

        <p>
          Our convention is that stub methods start with
          <code>setup&lt;state&gt;</code> to distinguish them from Java setter 
          methods which have the format <code>set&lt;state&gt;</code>. 
          Stub values are used by mock implementations of real methods.
        </p>

        <p>
          One unusual stub setting we use quite often is to force exceptions 
          to be thrown. For example, the mock sql statement includes the 
          method :
        </p>

<source><![CDATA[
  public void setupThrowExceptionOnExecute(SQLException exception);
]]></source>

        <p>
          The statement stores the given exception object and throws it when 
          <code>execute()</code> is called. This technique is sometimes the 
          only way to test certain types of failure.
        </p>

      </s2>

    </s1>

  </body>
</document>

[Mockobjects-java-dev] CVS: mockobjects-java/doc/xdocs doc-book.xml,1.5,1.6 site-book.xml,1.5,1.6 coding_conventions.xml,1.1,NONE

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

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

Modified Files:
	doc-book.xml site-book.xml 
Removed Files:
	coding_conventions.xml 
Log Message:
renamed "coding conventions" into "naming conventions" as this is what they are. Will add coding conventions which will be the coding conventions used internally by the Mock Objects project on its code (this will be for developers only, not for end users, whereas the naming conventions are useful to end users).

Index: doc-book.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/doc-book.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- doc-book.xml	2001/08/05 20:13:19	1.5
+++ doc-book.xml	2001/08/21 10:35:10	1.6
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 
-<book software="Mock Objects" 
-      title="Local Mock Object Documentation" 
+<book software="Mock Objects"
+      title="Local Mock Object Documentation"
       copyright="@year@ Mock Objects"
       updated="@today@">
 
@@ -18,17 +18,20 @@
 
   <menu label="Documentation">
     <menu-item label="What is it ?" source="endotesting.xml"/>
-    <menu-item label="Coding conventions" source="coding_conventions.xml"/>
+    <menu-item label="Naming conventions" source="naming_conventions.xml"/>
     <menu-item type="external" label="API Reference" href="javadoc/index.html"/>
   </menu>
 
   <menu label="Support">
-    <menu-item type="external" label="CVS" 
-        href="http://sourceforge.net/cvs/?group_id=18189"/>
-    <menu-item type="external" label="Bug database" 
+    <menu-item type="external" label="Bug database"
         href="http://sourceforge.net/tracker/?atid=118189&amp;group_id=18189&amp;func=browse"/>
-    <menu-item type="external" label="Mailing list" 
+    <menu-item type="external" label="Mailing list"
         href="http://sourceforge.net/mail/?group_id=18189"/>
+  </menu>
+
+  <menu label="Developers">
+    <menu-item type="external" label="CVS"
+        href="http://sourceforge.net/cvs/?group_id=18189"/>
   </menu>
 
 </book>

Index: site-book.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/doc/xdocs/site-book.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- site-book.xml	2001/08/05 20:13:19	1.5
+++ site-book.xml	2001/08/21 10:35:10	1.6
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
 
-<book software="Mock Objects" 
-      title="Mock Objects Documentation" 
+<book software="Mock Objects"
+      title="Mock Objects Documentation"
       copyright="@year@ Mock Objects"
       updated="@today@">
 
@@ -18,17 +18,20 @@
 
   <menu label="Documentation">
     <menu-item label="What is it ?" source="endotesting.xml"/>
-    <menu-item label="Coding conventions" source="coding_conventions.xml"/>
+    <menu-item label="Naming conventions" source="naming_conventions.xml"/>
     <menu-item type="external" label="API Reference" href="javadoc/index.html"/>
   </menu>
 
   <menu label="Support">
-    <menu-item type="external" label="CVS" 
-        href="http://sourceforge.net/cvs/?group_id=18189"/>
-    <menu-item type="external" label="Bug database" 
+    <menu-item type="external" label="Bug database"
         href="http://sourceforge.net/tracker/?atid=118189&amp;group_id=18189&amp;func=browse"/>
-    <menu-item type="external" label="Mailing list" 
+    <menu-item type="external" label="Mailing list"
         href="http://sourceforge.net/mail/?group_id=18189"/>
+  </menu>
+
+  <menu label="Developers">
+    <menu-item type="external" label="CVS"
+        href="http://sourceforge.net/cvs/?group_id=18189"/>
   </menu>
 
 </book>

--- coding_conventions.xml DELETED ---

[Mockobjects-java-dev] CVS: mockobjects-java/src/examples/com/mockobjects/examples/password TestForgotPasswordServlet.java,NONE,1.1 PasswordReminder.java,NONE,1.1 NotFoundException.java,NONE,1.1 MockPasswordReminder.java,NONE,1.1 ForgotPasswordServlet.java,NONE,1.1 AllTests.java,NONE,1.1

[Steve F. <sm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/examples/com/mockobjects/examples/password
In directory usw-pr-cvs1:/tmp/cvs-serv31451

Added Files:
	TestForgotPasswordServlet.java PasswordReminder.java 
	NotFoundException.java MockPasswordReminder.java 
	ForgotPasswordServlet.java AllTests.java 
Log Message:
First version of password reminder servlet

--- NEW FILE: TestForgotPasswordServlet.java ---
package com.mockobjects.examples.password;

import java.util.Enumeration;
import java.io.IOException;
import javax.servlet.ServletConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import junit.framework.AssertionFailedError;
import com.mockobjects.servlet.MockHttpServletRequest;
import com.mockobjects.servlet.MockHttpServletResponse;
import com.mockobjects.util.TestCaseMo;

public class TestForgotPasswordServlet extends TestCaseMo {
    public static final String SENT_URI = "sent_uri";
    public static final String EMAIL_FAILED_URI = "bademail_uri";
    public static final String EMAIL_NOT_FOUND_URI = "noemail_uri";
    public static final String EMAIL = "em...@an...dress";

    public TestForgotPasswordServlet(String name) {
        super(name);
    }

    private ForgotPasswordServlet passwordServlet = new ForgotPasswordServlet();
    private MockHttpServletRequest mockRequest = new MockHttpServletRequest();
    private MockHttpServletResponse mockResponse = new MockHttpServletResponse();
    private MockPasswordReminder mockReminder = new MockPasswordReminder();

    public void setUp() throws ServletException, IOException {
        mockRequest.setupAddParameter(ForgotPasswordServlet.EMAIL_PARAM, EMAIL);
        passwordServlet.init(createStubServletConfig(), mockReminder);
    }

    public void testReminderEmailSent() throws ServletException, IOException  {
        mockReminder.setExpectedEmailAddress(EMAIL);
        mockResponse.setExpectedRedirect(SENT_URI + "?email=" + EMAIL);

        passwordServlet.doGet(mockRequest, mockResponse);

        mockResponse.verify();
        mockReminder.verify();
    }

    public void testNoPasswordForEmail() throws ServletException, IOException  {
        mockReminder.setupEmailNotFound();

        mockReminder.setExpectedEmailAddress(EMAIL);
        mockResponse.setExpectedRedirect(EMAIL_NOT_FOUND_URI + "?email=" + EMAIL);

        passwordServlet.doGet(mockRequest, mockResponse);

        mockResponse.verify();
        mockReminder.verify();
    }

    private ServletConfig createStubServletConfig() {
        return new ServletConfig() {
            public String getInitParameter(String s) {
                if (ForgotPasswordServlet.SENT_PARAM_NAME.equals(s)) {
                    return SENT_URI;
                } else if (ForgotPasswordServlet.EMAIL_FAILED_PARAM_NAME.equals(s)) {
                    return EMAIL_FAILED_URI;
                } else if (ForgotPasswordServlet.EMAIL_NOT_FOUND_PARAM_NAME.equals(s)) {
                    return EMAIL_NOT_FOUND_URI;
                }
                throw new AssertionFailedError("not expected: " + s);
            }

            public Enumeration getInitParameterNames() {
                throw new AssertionFailedError("not expected");
            }

            public ServletContext getServletContext() {
                throw new AssertionFailedError("not expected");
            }

            public String getServletName() {
                throw new AssertionFailedError("not expected");
            }
        };
    }
}


--- NEW FILE: PasswordReminder.java ---
package com.mockobjects.examples.password;

public interface PasswordReminder {
    public void sendReminder(String emailAddress) throws NotFoundException;
}

--- NEW FILE: NotFoundException.java ---
package com.mockobjects.examples.password;

public class NotFoundException extends Exception {
    public NotFoundException() {
        super();
    }

    public NotFoundException(String s) {
        super(s);
    }
}

--- NEW FILE: MockPasswordReminder.java ---
package com.mockobjects.examples.password;

import com.mockobjects.ExpectationValue;
import com.mockobjects.MockObject;

public class MockPasswordReminder extends MockObject implements PasswordReminder {
    private ExpectationValue emailAddress = new ExpectationValue("MockPasswordReminder email");
    private boolean emailNotFound = false;

    public void sendReminder(String anEmailAddress) throws NotFoundException {
        emailAddress.setActual(anEmailAddress);
        if (emailNotFound) {
            throw new NotFoundException("Not found: "  + anEmailAddress);
        }
    }

    public void setExpectedEmailAddress(String anEmailAddress) {
        emailAddress.setExpected(anEmailAddress);
    }

    public void setupEmailNotFound() {
        emailNotFound = true;
    }
}

--- NEW FILE: ForgotPasswordServlet.java ---
package com.mockobjects.examples.password;

import java.io.IOException;
import javax.servlet.ServletException;
import javax.servlet.ServletConfig;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class ForgotPasswordServlet extends HttpServlet {
    public static final String SENT_PARAM_NAME = "sent";
    public static final String EMAIL_FAILED_PARAM_NAME = "bademail";
    public static final String EMAIL_NOT_FOUND_PARAM_NAME = "noemail";
    public static final String EMAIL_PARAM = "email";

    private PasswordReminder passwordReminder;

    public void init(ServletConfig config, PasswordReminder aPasswordReminder) throws ServletException {
        super.init(config);
        passwordReminder = aPasswordReminder;
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        String emailAddress = request.getParameter(EMAIL_PARAM);

        try {
            passwordReminder.sendReminder(emailAddress);
            redirectFor(SENT_PARAM_NAME, response, emailAddress);

        } catch (NotFoundException ex) {
            redirectFor(EMAIL_NOT_FOUND_PARAM_NAME, response, emailAddress);
        }
    }

    private void redirectFor(String baseName, HttpServletResponse response, String emailAddress) throws IOException {
        response.sendRedirect(getInitParameter(baseName) + "?email=" + emailAddress);
    }

}

--- NEW FILE: AllTests.java ---
package com.mockobjects.examples.password;

import junit.framework.Test;
import junit.framework.TestSuite;
import com.mockobjects.util.SuiteBuilder;
import com.mockobjects.util.TestCaseMo;
import com.mockobjects.examples.calcserver.TestCalculator;
import com.mockobjects.examples.calcserver.TestCalculatorServlet;
import com.mockobjects.examples.calcserver.TestSavingCalculator;

public class AllTests extends TestCaseMo {
    private static final Class THIS = AllTests.class;

    public AllTests(String name) {
        super(name);
    }


    public static void addForgotPasswordServlet(TestSuite suite) {
        suite.addTestSuite(TestForgotPasswordServlet.class);
    }


    public static void main(String[] args) {
        start(new String[]{ THIS.getName()});
    }


    public static Test suite() {
        return SuiteBuilder.buildTest(THIS);
    }
}

[Mockobjects-java-dev] CVS: mockobjects-java/src/examples/com/mockobjects/examples/password - New directory

[Steve F. <sm...@us...>]

Update of /cvsroot/mockobjects/mockobjects-java/src/examples/com/mockobjects/examples/password
In directory usw-pr-cvs1:/tmp/cvs-serv15612/password

Log Message:
Directory /cvsroot/mockobjects/mockobjects-java/src/examples/com/mockobjects/examples/password added to the repository

[Mockobjects-java-dev] mockmaker conventions updated

[ivan m. <iv...@ta...>]

I have released a new version of MockMaker which
tries to conform to the mockobjects method naming 
conventions in what it does. 

Formating and naming of the rest of the code 
that MockMaker produces and the source code 
for MockMaker will take a little longer to get changed ...

please let me know what you think folks, and
put any stories on the appropriate wiki page
linked on the mockmaker homepage 

http://mockmaker.sourceforge.net

Ivan Moore




----------------------------------------------------------
This message was sent using                 http://uk2.net
NEWS - CHEAPEST DEDICATED SERVERS IN THE WORLD -  25/month
FREE UK DIAL 0845 609 1370 - username uk2: - password: uk2
UK's FREE Domains, FREE Dialup, FREE Webdesign, FREE email

[Mockobjects-java-dev] CVS: mockobjects-java/conf/.Refactory pretty.settings,NONE,1.1

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

Update of /cvsroot/mockobjects/mockobjects-java/conf/.Refactory
In directory usw-pr-cvs1:/tmp/cvs-serv2751/conf/.Refactory

Added Files:
	pretty.settings 
Log Message:
Added a target in build.xml to reformat code (called 'format'). It uses JRefactory Pretty Printer (http://jrefactory.sourceforge.net/cspretty.html). The JRefactory jar need to be put in $ANT_HOME/lib. Be careful, when you execute this target it reformats all the java source code in the <mockobjects>/src directory. So if you want to test it, edit your build.xml and explicitely put the name of the java file on which you would like to test it ! The JRefactory settings are in <mockobjects>/conf/.Refactory/pretty.settings

--- NEW FILE: pretty.settings ---
#  Pretty.settings
version=1.0
#  This is the number of spaces to indent for each block.
#  Twice this number is the amount of space used for
#  unexpected carrage returns.
indent=4
indent.char=space

#  Style for { and }
#  C style means that { is at the end of the line
#  and } is on a line by itself.  For example,
#  if (myTest) {
#    //  This is c style
#  }
#
#  PASCAL style means both { and } are on lines
#  by themselves.  For example,
#  if (myTest)
#  {
#    //  This is PASCAL style
#  }
block.style=C

#  The following parameter should be changed to true if you
#  like your parens to have a space before and after them
#  if ( x == y )    //expr.space=true
#  if (x == y)      //expr.space=false
expr.space=false

#  The following parameter is the minimum number of blank lines
#  between methods, nested classes, and nested interfaces.
#  It is also the number of lines before and after
#  field declarations, though field declarations will have
#  what ever spacing you used.
#
#  Note that this is a minimum.  If your code already
#  has more space between methods, then it won't shrink
#  the number of blank lines.
lines.between=1


#
#  Default Javadoc comments
#
#  The following items are used by the mechanism that
#  automatically inserts javadoc comments.  Other than
#  author (which I recommend that you change), these
#  values are probably sufficient.  However, if you
#  want to make it easer to search your files to find
#  where the values are missing, you can change these
#  to something more unique.
#

#  Author - the default author
author=<a href="mailto:vm...@ap...">Vincent Massol</a>

#  Default description of the class
class.descr=Description of the Class

#  Default description of the interface
interface.descr=Description of the Interface

#  Default description of the constructor  {0} stands for the name
#  of the constructor
constructor.descr=Constructor for the {0} object

#  Default description of the method
method.descr=Description of the Method

#  Default description of the parameter
param.descr=Description of Parameter

#  Default description of the return value
return.descr=Description of the Returned Value

#  Default description of the exception
exception.descr=Description of Exception

#  Pretty.settings
version=1.1
#  Default description of the getter.  {0} is the name of the
#  attribute, {1} is the name of the class, {2} is 'class'
#  or 'object' depending on whether it is static or not
getter.descr=Gets the {0} attribute of the {1} {2}

#  Default description of the setter.  {0} is the name of the
#  attribute, {1} is the name of the class, {2} is 'class'
#  or 'object' depending on whether it is static or not
setter.descr=Sets the {0} attribute of the {1} {2}

#  Parameter description for setters.  {0} is the name of the attribute
setter.param.descr=The new {0} value

#  Return description for getters.  {0} is the name of the attribute
getter.return.descr=The {0} value

#
#  Sort order
#
#  To change the relative priorities of the sort, adjust the number after
#  the dot.  For instance, if you want all the instance parts first then
#  static parts second, and within these you want the field, constructor etc
#  to be sorted next, switch the number of sort.1 and sort.2.


#  Check the type first
#    This places the fields first, and initializers last.  Note that to keep
#    things compiling initializers must be after the fields.
sort.1=Type(Field,Initializer,Constructor,Method,NestedClass,NestedInterface)

#  Check the class/instance next
#    To place the static methods and variables first, switch the order
#    of instance and static.
sort.2=Class(Instance,Static)

#  Check the protection next
#    To sort with public methods/variables use Protection(public)
#    To sort with private methods/variables use Protection(private)
sort.3=Protection(public)

#  Group setters and getters last
#    Setters are methods that start with the word 'set'
#    Getters are methods that start with the word 'get' or 'is'
sort.4=Method(setter,getter,other)

#  Pretty.settings
version=1.2

#  Limits the level that javadoc comments are forced
#  into the document.  The following are valid
#  levels:
#  *  all - all items must have javadoc
#  *  private - same as all
#  *  package - all items except private items must have javadoc
#  *  default - same as package
#  *  protected - protected and public items must have javadoc
#  *  public - only public items must have javadoc
#  *  none - nothing is required to have javadoc
#
#  method.minimum applies to constructors and methods
method.minimum=none

#  field.minimum applies to fields
field.minimum=none

#  Default field description
field.descr=Description of the Field

#  Default description of the run method.  {0} is the name of the
#  attribute, {1} is the name of the class, {2} is 'class'
#  or 'object' depending on whether it is static or not
run.descr=Main processing method for the {1} {2}


#  Default description of the run method.  {0} is the name of the
#  attribute, {1} is the name of the class, {2} is 'class'
#  or 'object' depending on whether it is static or not
main.descr=The main program for the {1} {2}

#  Description of the main arguments
main.param.descr=The command line arguments

#  Is the date a required field of the class or interface
date.required=false

#  Pretty.settings
version=1.3

#  Default description of the add method.  {0} is the name of the
#  attribute, {1} is the name of the class, {2} is 'class'
#  or 'object' depending on whether it is static or not
adder.descr=Adds a feature to the {0} attribute of the {1} {2}

#  Description of the add argument
adder.param.descr=The feature to be added to the {0} attribute




#  Pretty Printer Version
version=1.4
#  JUnit has a particular format for the names of methods.
#  These setup for the unit tests are done in a method named
#  setUp, the cleanup afterwards is done in tearDown, and
#  the unit tests all start with the word test.  The following
#  are the default descriptions of these methods.
junit.setUp.descr=The JUnit setup method

junit.test.descr=A unit test for JUnit

junit.tearDown.descr=The teardown method for JUnit

junit.suite.descr=A suite of unit tests for JUnit
junit.suite.return.descr=The test suite

#  class.minimum applies to classes and interfaces
class.minimum=none



#  Pretty Printer Version
version=1.5

#  Is there a space after the cast
cast.space=false

#  Star count for javadoc
javadoc.star=2

#  Wordwrap length for javadoc.  You must have at least
#  javadoc.wordwrap.min characters in the comment and you
#  must be passing javadoc.wordwrapp.max for the indenting
#  plus the comment
javadoc.wordwrap.max=78
javadoc.wordwrap.min=40

#  Pretty Printer Version
version=1.6

#
#  Header:
#  Uncomment these lines if you would like
#  a standard header at the beginning of each file.
#  You are allowed an unlimited number of lines here,
#  just number them sequentially.
#
header.1=/*
header.2= * The Apache Software License, Version 1.1
header.3= *
header.4= * Copyright (c) 1999 The Apache Software Foundation.  All rights
header.5= * reserved.
header.6= *
header.7= * Redistribution and use in source and binary forms, with or without
header.8= * modification, are permitted provided that the following conditions
header.9= * are met:
header.10= *
header.11= * 1. Redistributions of source code must retain the above copyright
header.12= *    notice, this list of conditions and the following disclaimer.
header.13= *
header.14= * 2. Redistributions in binary form must reproduce the above copyright
header.15= *    notice, this list of conditions and the following disclaimer in
header.16= *    the documentation and/or other materials provided with the
header.17= *    distribution.
header.18= *
header.19= * 3. The end-user documentation included with the redistribution, if
header.20= *    any, must include the following acknowlegement:
header.21= *       "This product includes software developed by the
header.22= *        Apache Software Foundation (http://www.apache.org/)."
header.23= *    Alternately, this acknowlegement may appear in the software itself,
header.24= *    if and wherever such third-party acknowlegements normally appear.
header.25= *
header.26= * 4. The names "The Jakarta Project", "Ant", and "Apache Software
header.27= *    Foundation" must not be used to endorse or promote products derived
header.28= *    from this software without prior written permission. For written
header.29= *    permission, please contact ap...@ap....
header.30= *
header.31= * 5. Products derived from this software may not be called "Apache"
header.32= *    nor may "Apache" appear in their names without prior written
header.33= *    permission of the Apache Group.
header.34= *
header.35= * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
header.36= * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
header.37= * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
header.38= * DISCLAIMED.  IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
header.39= * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
header.40= * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
header.41= * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
header.42= * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
header.43= * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
header.44= * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
header.45= * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
header.46= * SUCH DAMAGE.
header.47= * ====================================================================
header.48= *
header.49= * This software consists of voluntary contributions made by many
header.50= * individuals on behalf of the Apache Software Foundation.  For more
header.51= * information on the Apache Software Foundation, please see
header.52= * <http://www.apache.org/>.
header.53= */


#  Pretty Printer Version
version=1.7
#  The following allow you to require and order
#  tags for the classes, methods, and fields.  To
#  require the tag, add the name of the tag here
#  and then add a TAGNAME.descr field.  To only
#  specify the order, just include the tag here.

#  Here is the order for tags for classes and interfaces
class.tags=author

#  Here is the order for tags for methods and constructors
method.tags=param,return,exception,since

#  Here is the order for tags for fields
field.tags=since

#  In all tags that are required, there are some parameters
#  that are available.  These are:
#  {0} refers to the current user
#  {1} refers to the current user
#  {2} refers to the name of the current object

#  Now we are ready to specify the author
author.descr=<a href="mailto:vm...@ap...">Vincent Massol</a>

#  Now we are ready to specify the created tag
created.descr={1}


#  Pretty Printer Version
version=2.2

#  Whether we put a space before the @
space.before.javadoc=true

#  Should we sort the types and imports?
sort.top=false

#  Should catch statements look like
#  (true) is:
#  try {
#      //  Something here
#  }
#  catch (IOException ioe) {
#      //  Something here
#  }
#  (false) is:
#  try {
#      //  Something here
#  } catch (IOException ioe) {
#      //  Something here
#  }
#  This value is also used for else statements
catch.start.line=false

#  This determines if there should be a space after keywords
#  When this value is true, you get:
#  if (true) {
#      //  Do something
#  }
#  When this value is false, you get:
#  if(true) {
#      //  Do something
#  }
keyword.space=true


#
#  Do you want to lineup the names and descriptions
#  in javadoc comments?
#
javadoc.id.lineup=true

#
#  How many spaces should javadoc comments be indented?
#
javadoc.indent=1

#
#  What do you do when a newline is unexpectedly encountered?
#  The valid values are double and param.  Double means that
#  you should indent twice.  Param means try to line up the
#  the parameters.
#
surprise.return=double

#
#  To handle sun's coding standard, you want the method to begin
#  with a PASCAL coding style and the {} beneath that to be C style.
#  This parameter allows you to set the method style different
#  from the rest.
#
method.block.style=PASCAL

#
#  Should throws part of a method/constructor declaration always be
#  on it's own line?
#
throws.newline=false


#  Pretty Printer Version
version=3.0


#
#  Wordwrap the javadoc comments
#
reformat.comments=true

#
#  Single line comment type
#

#
#  Should each single line comment be indented a certain number of spaces
#  from the margin?  For this to work right be sure to indent each line with
#  spaces.
#
singleline.comment.ownline=true


#
#  Indent the name of the field to this column (-1 for just one space)
#
field.name.indent=-1


#
#  Include javadoc comments where ever they appear
#
keep.all.javadoc=false


#
#  End of line character(s) - either CR, CRNL, or NL
#  CR means carriage return, NL means newline
#
end.line=CRNL

#
#  Absolute indent before a single line comment.
#
singleline.comment.absoluteindent=0

#
#  Space used before the start of a single line 
#  from the end of the code
#
singleline.comment.incrementalindent=0

#
#  This feature describes how the pretty printer should 
#  indent single line comments (//) that share the line
#  with source code.  The two choices are incremental and absolute.
#    incremental  -  use an incremental indent
#    absolute  -  use the absolute indent level
#
singleline.comment.indentstyle.shared=incremental

#
#  This feature describes how the pretty printer should
#  indent single line comments (//) that are on their
#  own line.  The two choices are code and absolute.
#    code  -  use the same indent as the current code
#    absolute  -  use the absolute indent level
#
singleline.comment.indentstyle.ownline=code

#
#  This feature describes what type of characters are used for
#  the java files.
#    1 - ASCII (1 byte characters)
#    2 - Unicode (2 byte characters - far east)
#
char.stream.type=1

#
#  This features sprecifies how to space out a field or a local
#  variable declaration.
#    single - a space between the modifiers, the type, the name 
#        and the initializer
#    dynamic - determine the spacing between the modifiers, type, 
#        name, and initializers so everything lines up
#
variable.spacing=single


#  Pretty Printer Version
version=3.1

#
#  When a dynamic field spacing is used, this value specifies
#  the number of additional spaces to add between the modifiers, 
#  type, name, and initializer.
#
dynamic.variable.spacing=1


#  Pretty Printer Version
version=3.2

#
#  How to format C Style comments.  Valid values are:
#    leave - leave alone
#    align.star - place a row of stars to the right and align on those
#    align.blank - just align the comments to the right (no star)
#
c.style.format=align.star

#
#  For one of the methods above that use the align type, this is
#  the number of spaces to include after the * or blank
#
c.style.indent=2


#  Pretty Printer Version
version=3.3

#
#  Empty methods and constructors remain on a single line
#
empty.block.single.line=false


#  Pretty Printer Version
version=3.4

#
#  Do we force a space after a cast?
#
cast.force.nospace=false


#  Pretty Printer Version
version=3.5

#
#  What tag name should be used for exceptions
#
exception.tag.name=@exception


#  Pretty Printer Version
version=3.6

#
#  Should inner classes be documented
#
document.nested.classes=true

#
#  Should the document have a footer.  Include it here.
#  To include more lines, just add more values
#
#footer.1=
#footer.2=//  This is the end of the file
#footer.3=

#  Pretty Printer Version
version=3.7

#
#  Should the local variables be aligned with the { and }
#  or should they be indented to align with the other code?
#  false means align with the code, true means align
#  with the { }
#
variable.align.with.block=false

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

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

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

Modified Files:
	build.xml 
Log Message:
Added a target in build.xml to reformat code (called 'format'). It uses JRefactory Pretty Printer (http://jrefactory.sourceforge.net/cspretty.html). The JRefactory jar need to be put in $ANT_HOME/lib. Be careful, when you execute this target it reformats all the java source code in the <mockobjects>/src directory. So if you want to test it, edit your build.xml and explicitely put the name of the java file on which you would like to test it ! The JRefactory settings are in <mockobjects>/conf/.Refactory/pretty.settings

Index: build.xml
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/build.xml,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- build.xml	2001/08/15 14:17:09	1.11
+++ build.xml	2001/08/20 16:21:09	1.12
@@ -602,4 +602,24 @@
 
     </target>
 
+    <!--
+       ========================================================================
+         Formats the source code using JRefactory Pretty Printer. The
+         JRefactory jar need to be place in ${ANT_HOME}/lib.
+       ========================================================================
+    -->
+    <target name="format" depends="init"
+        description="reformats all java code">
+
+        <taskdef name="pretty" classname="org.acm.seguin.ant.Pretty"/>
+
+        <pretty settingsdir="${conf.dir}">
+            <fileset dir="${src.dir}">
+                <!-- Be careful, it's going to reformat all code ! -->
+                <include name="**/*.java"/>
+            </fileset>
+        </pretty>
+
+    </target>
+
 </project>

[Mockobjects-java-dev] CVS: mockobjects-java/conf/.Refactory - New directory

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

Update of /cvsroot/mockobjects/mockobjects-java/conf/.Refactory
In directory usw-pr-cvs1:/tmp/cvs-serv1487/.Refactory

Log Message:
Directory /cvsroot/mockobjects/mockobjects-java/conf/.Refactory added to the repository

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

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

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

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

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

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

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

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

PiBBcyBsb25nIGFzIHRoZSByZWZlcmVuY2VzIGluIHRoZSBvdXRlciBjbGFzcyBhcmUgZmluYWws
IHdlIGNhbiB1c2UgYW55IG9mDQo+IHRoZSBFeHBlY3RhdGlvbi1pbXBsZW1lbnRpbmcgY2xhc3Nl
cyBvZiBjb20ubW9ja29iamVjdHMuKiAqYW55d2hlcmUqIGluIHRoZQ0KPiB0ZXN0LCBpbmNsdWRp
bmcgaW4gdGhlIGFub255bW91cyBpbm5lciBjbGFzcyBtZXRob2RzLCBhbmQgY2FsbCB0aGVpciB2
ZXJpZnkNCj4gbWV0aG9kcyBhdCB0aGUgZW5kIG9mIHRlc3QgYXMgYXBwcm9wcmlhdGUuIFNvIGZh
ciwgdGhyb3VnaCByZWZhY3RvcmluZyBhbmQNCj4gZGVtZXRlci1iYXNlZCBtZXRob2QgZGVzaWdu
IG9mIHRoZSBwcm9kdWN0aW9uIGNsYXNzZXMsIG15IGV4cGVyaWVuY2UgaXMgdGhhdA0KPiB0aGUg
c2ltcGxlIGNvdW50ZXIgc3VmZmljZXMuIERvIHlvdSBoYXZlIGFueSBjb21wbGV4IGNsYXNzIGV4
YW1wbGVzIHdoZXJlDQo+IGRvaW5nIHZlcmlmaWNhdGlvbnMgaW4gdGhlIGlubmVyIGNsYXNzIGFu
ZCBjaGVja2luZyB0aGUgbnVtYmVyIG9mIG1ldGhvZA0KPiBjYWxscyB2aWEgYSBjb3VudGVyIGlz
IG5vdCBhZGVxdWF0ZT8NCg0KaW4gc29tZSBvZiB0aGUgY29kZSBJJ3ZlIGJlZW4gd29ya2luZyB3
aXRoLCBzdWNoIGFzIGFwcGxpY2F0aW9uIHNlcnZlcnMsIGVhY2ggdGVzdCBtYXkgaW52b2x2ZSBz
ZXZlcmFsIG1vY2sgb2JqZWN0cy4gUHV0dGluZyBhbGwgb2YgdGhvc2UgaW50byBhIHNpbmdsZSBt
ZXRob2Qgd291bGQgZ2V0IHJhdGhlciBsYXJnZS4NCiANCj4gIkFyZSB5b3Ugc2F5aW5nIHRoYXQg
dGhlIHRyaWNrIGlzIHRvIGltcGxlbWVudCBpbiB0aGUgaW5uZXIgY2xhc3Mgb25seSB0aG9zZQ0K
PiBtZXRob2RzIHlvdSBuZWVkIGZvciB0aGUgY3VycmVudCB0ZXN0PyBJZiBzbywgdGhhdCBuZWVk
IGNsYXJpZnlpbmcuIg0KPiANCj4gVGhpcyBpcyBwcmVjaXNlbHkgdGhlIHBvaW50LiBXZSBvbmx5
IG92ZXJyaWRlIHRoZSBtZXRob2RzIHdlIG5lZWQgZm9yIHRoZQ0KPiBjdXJyZW50IHRlc3QgYW5k
IG1ha2Ugb3VyIGFzc2VydGlvbnMgd2l0aGluIHRob3NlIG92ZXJyaWRkZW4gbWV0aG9kcy4gV2Ug
Y2FuDQo+IGFsc28sIGFzIGFib3ZlLCB1c2UgYW4gRXhwZWN0YXRpb25Db3VudGVyIHRvIGNoZWNr
IG1lc3NhZ2UgY2FsbHMuIElmIHRoaXMgaXMNCj4gbm90IGNsZWFyLCB3aGF0IGRvIHlvdSBzdWdn
ZXN0IHRvIG1ha2Ugc3VyZSBpdCBpcyBjbGVhcj8NCg0KVGhlIGlkZWEgaXMgaW50ZXJlc3Rpbmcg
YXMgYW5vdGhlciB0b29sIGluIHRoZSBib3guIEkgdGhpbmsgeW91IG5lZWQgdG8gYmUgbW9yZSBl
eHBsaWNpdCBhYm91dCBvbmx5IG92ZXJyaWRpbmcgdGhlIG1ldGhvZHMgeW91ciBpbnRlcmVzdGVk
IGluLiANCg0KT25lIHBvdGVudGlhbCBjYXRjaCBpcyBwcm90ZWN0aW9uIGFnYWluc3QgcmVmYWN0
b3JpbmcuIElmIHNvbWUgdGFyZ2V0IGNvZGUgY29kZSBjaGFuZ2VzIGFuZCBjYWxscyBhIGRpZmZl
cmVudCBtZXRob2QsIHlvdXIgdGVzdHMgbWF5IG5vdCBjYXRjaCBpdCwgb3IgYXQgbGVhc3Qgbm90
IG9idmlvdXNseS4NCg0KPiBQdXR0aW5nIEpESyAxLjMgYXNpZGUsIHRoZSBtb2NrIG9iamVjdHMg
cHJvamVjdCwgQUZBSUssIGlzIGRlcGVuZGVudCBvbiB0aGUNCj4gZXhpc3RlbmNlIG9mIGludGVy
ZmFjZXMgZm9yIGV2ZXJ5dGhpbmcgdGhhdCBpcyBtb2NrZWQuIElNTywgdGhpcyBpcyBhbg0KPiB1
bnJlYWxpc3RpYyBleHBlY3RhdGlvbiBvZiBhIHByb2plY3Qgd2hlcmUgaXQgaXMgbm90IGdlbmVy
YWxseSB1c2VmdWwgdG8NCj4gaGF2ZSBhbiBpbnRlcmZhY2UgZm9yIGV2ZXJ5IHNpbmdsZSBjbGFz
cywgZXNwZWNpYWxseSBwYWNrYWdlIHByb3RlY3RlZA0KDQpub3Qgc28uIFRoZSBvbmx5IHRoaW5n
IHdlIGNhbid0IGRvIGlzIGZpbmFsIGNsYXNzZXMgd2hpY2ggc2hvdWxkIGJlIHdyYXBwZWQgYW55
d2F5LiBXZSBzdWJjbGFzcyBmcm9tIHJlYWwgY2xhc3NlcyBhbmQgb3ZlcnJpZGUgZXZlcnl0aGlu
Zy4NCg0KV2UgZG8gdGVuZCB0byBoYXZlIGEgdHJpcGxlIChpbnRlcmZhY2UsIG1vY2ssIGFuZCBh
dCBsZWFzdCBvbmUgcmVhbCkgZm9yIGV2ZXJ5dGhpbmcuIEl0IGNhbiBiZSB0ZWRpb3VzLCBidXQg
dGhhdCdzIG1vcmUgYW4gSURFIGVudmlyb25tZW50IHRoYW4gYW55dGhpbmcgZWxzZS4gSSdtIHBy
ZXR0eSBzdXJlIHRoYXQgc29tZSBzdXBwb3J0IGNvdWxkIGJlIGF1dG9tYXRlZC4NCg0KV2UgYWxz
byB0ZW5kIG5vdCB0byBib3RoZXIgd2l0aCBwYWNrYWdlIHByb3RlY3Rpb24uIFdlIGRvbid0IGtu
b3cgd2hpY2ggY2xhc3NlcyB3aWxsIGJlIHVzZWZ1bCBpbiB0aGUgbG9uZyBydW4uIElmIHdlIHdh
bnQgdG8gc2VwYXJhdGUgYSBmcmFtZXdvcmsgd2UgY2FuIHB1dCB0aGUgaW50ZXJmYWNlcyBpbiBh
IGRpZmZlcmVudCBwYWNrYWdlLCBsaWtlIGp1bml0Lg0KDQpTdGV2ZQ0KDQo=

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

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

----- Original Message -----
From: "Thomas Calivera" <ald...@ne...>
To: <moc...@li...>
Sent: Friday, August 17, 2001 7:10 PM
Subject: Re: [Mockobjects-java-dev] mailing list configuration


> "I am subscribed to 20 mailing-lists and receive about 2000 mails *per
day*.
> Imagine my life without filtering, impossible "
>
> In recent news, analysis of Vincent Missal's various folders indicates
that
> at least 100 of the daily 2000 messages were from Vincent himself... <big>

:-)

>
> I currently use the bracketed list identification in the subject to sort
> emails out into different folders, but there is other information I can
use
> in the From and To fields, so I am indifferent to changing the mailing
list
> configuration.

I use the "to" field but as I said I have agreed to keep it as it is ... no
big deal ...

>
> Tom
-Vincent

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

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

"I am subscribed to 20 mailing-lists and receive about 2000 mails *per day*.
Imagine my life without filtering, impossible "

In recent news, analysis of Vincent Missal's various folders indicates that
at least 100 of the daily 2000 messages were from Vincent himself... <big>

I currently use the bracketed list identification in the subject to sort
emails out into different folders, but there is other information I can use
in the From and To fields, so I am indifferent to changing the mailing list
configuration.

Tom