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

[MO-java-dev] Why doesn't Mock check method parameter types as well as method names?

[Barry K. <bk...@in...>]

This is one of my most common issues. I refactor a method, removing or 
reording parameters. Then run tests. The tests do indeed fail, but the 
error is that a method was not called. When in the fact the expectation 
defined in the test is completely erroneous.

I can create the patch, but first want to check if there is some reason 
for why it is the way it is.

RE: [MO-java-dev] Web site generation question

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

Can we all work together to transfer what we have in CVS to this wiki.
I'll start working on that too tonight. Then tomorrow night I'll remove
our doc/ directory from CVS and perform the 0.08 release. Steve can
perform the DNS change tomorrow night too.

Is that ok?

Thanks
-Vincent

> -----Original Message-----
> From: Steve Freeman [mailto:st...@m3...]
> Sent: 15 May 2003 19:32
> To: Vincent Massol
> Cc: 'Mockobjects-Java-Dev'
> Subject: Re: [MO-java-dev] Web site generation question
> 
> Once you think it's ready, we can flip the home page on
mockobjects.com
> 
> S.
> 
> Joe Walnes wrote:
> >>
> >>
> >> Oh ok. That's cool. What's the URL? Let's move all our stuff on the
> wiki
> >> if we all agree then.
> >>
> > http://wiki.truemesh.com/mockobjects/
> >
> > It's naked at the moment but easy to grow. If you setup user
preferences
> > you can be notified of any changes via email by using the .* regexp.
> >
> > -joe

Re: [MO-java-dev] Web site generation question

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

Once you think it's ready, we can flip the home page on mockobjects.com

S.

Joe Walnes wrote:
>>
>>
>> Oh ok. That's cool. What's the URL? Let's move all our stuff on the wiki
>> if we all agree then.
>>
> http://wiki.truemesh.com/mockobjects/
> 
> It's naked at the moment but easy to grow. If you setup user preferences 
> you can be notified of any changes via email by using the .* regexp.
> 
> -joe

Re: [MO-java-dev] Web site generation question

[Joe W. <jo...@tr...>]

>
>
>Oh ok. That's cool. What's the URL? Let's move all our stuff on the wiki
>if we all agree then.
>
http://wiki.truemesh.com/mockobjects/

It's naked at the moment but easy to grow. If you setup user preferences 
you can be notified of any changes via email by using the .* regexp.

-joe

Re: [MO-java-dev] dynamic.CallBag which allows any number of calls

[Barry K. <bk...@in...>]

Tim Mackinnon wrote:

> Barry -
> 
> Is this a question about the current head version vs. the branch version?

Head from 30 April.

> The new branch doesn't support this but its easy to add. ExpectedCall should
> be copied (or subclassed not sure which) to CallAtLeastOnce and the method
> matches reimplmented (e.g. return delegate.matches( methodName, args );
> (When we get into the head version, ExpectedCall should be renamed to
> CallOnlyOnce).  Subclass DefaultCallFactory and override createExpectedCall
> to return your CallAtLeastOnce. Create a Mock with the new factory (or
> subclass and have RelaxedMock the specifies the factory).

Hmm. I'll have to look at the branch. What is its state? Usable? Stable?

-bk

Re: [MO-java-dev] dynamic.CallBag which allows any number of calls

[Barry K. <bk...@in...>]

Tim Mackinnon wrote:

> Actually if its just for getters and you just want to specify a return value
> (and not bother setting an expectation, just use matchAndReturn). Or use
> both to get an initial expectation and then a default (and then no need for
> a special factory)
> 
> expectAndReturn("getX", 5);
> matchAndReturn("getX", 5);

Ah! This is probably what I want. Thanks.

Part of my problem is that I have not been using Mock.class until just 
recently. I have been using the subclasses of Call and integrating them 
with our existing simple mocks.

Let me ask another question: The other reason I hacked CallSet was to 
support mutliple calls but in any order. Is that that the default 
behavior for Mock.class?

[MO-java-dev] [new dyna mock] Bug?

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

Hi,

I have the following 2 tests:

    public void testCreateOrderOk() throws Exception
    {
        mockQueueConnectionFactory.expectAndReturn(
            "createQueueConnection", queueConnection);

        int orderId = petstore.createOrder(new Date(), "item1");
        
        assertEquals(1234, orderId);
    }

    public void testCreateThrowsOrderException() throws Exception
    {
        mockQueueConnectionFactory.expectAndThrow(
            "createQueueConnection", new JMSException("error"));

        try
        {
            petstore.createOrder(new Date(), "item1");
            fail("Should have thrown an EJBException");
        }
        catch (EJBException expected)
        {
            assertEquals("error", 
                expected.getCausedByException().getMessage());
        }
    }

The second test (testCreateThrowsOrderException()) fails with the
following error:

junit.framework.AssertionFailedError: mockQueueConnectionFactory:
Unexpected call: createQueueConnection()
Expected one of:
createQueueConnection() [called]
[...]

If I comment out the testCreateOrderOk() method it works...

It seems that the 2 tests are overstepping each other and that the
second mock expectAndThrow() is not taken into account because the mock
has already been set up by the first test! Glurps....

Any idea? Do we have a test case for this scenario in our test suite?

Thanks
-Vincent

RE: [MO-java-dev] Web site generation question

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

> -----Original Message-----
> From: Steve Freeman [mailto:st...@m3...]
> Sent: 15 May 2003 03:43
> To: Vincent Massol
> Cc: 'Jeff Martin'; 'Mockobjects-Java-Dev'
> Subject: Re: [MO-java-dev] Web site generation question
> 
> Vincent Massol wrote:
> > Thanks Jeff for the explanation! Now we need to know what we want:
> > - remove the xdocs from CVS altogether?
> > - or continue to use the xdocs (which are really simplified HTML)
and
> > simply perform a simple XSLT transform (using the Ant <style> task)?
> 
> There's a further issue. Joe has kindly set us up with a project wiki
> which should reduce some of the pain of keeping the site up to date.

Oh ok. That's cool. What's the URL? Let's move all our stuff on the wiki
if we all agree then.

> 
> My suggestion is to do whichever option is easiest for now, just to
get
> the release out, and then think about what to do next.
> 
> Part of the problem is that I don't think anyone's active in any of
the
> jakarta projects, so there's a (small) learning curve for working with
> the tools that, frankly, we haven't had time to climb. I'm also all
for
> reducing dependencies on other infrastructure, given that it's such a
> small project.

Ok. I just needed to know what we should use because I have been
updating the xdocs files and found that when generating the web site,
our build wasn't processing them any more! So I have done some work for
nothing...

I'd like to get the wiki URL, quickly move all our stuff and remove all
the doc/ directory from our CVS (I'd still be in the Attic though in
case we need to go back to it in the future).

Is that ok?

Thanks
-Vincent

> 
> S.
> 

RE: [MO-java-dev] First batch of questions on new Dynamic Mock API

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

> -----Original Message-----
> From: Steve Freeman [mailto:st...@m3...]
> Sent: 15 May 2003 04:00
> To: Vincent Massol
> Cc: 'Tim Mackinnon'; 'Mockobjects-Java-Dev'
> Subject: Re: [MO-java-dev] First batch of questions on new Dynamic
Mock
> API
> 
> Vincent Massol wrote:
> > and 2/ willing to do so). Thus, the project manager has tasked me to
> > write the missing MockObjects.com missing documentation for our
> > project... *sigh* I have been postponing this as I also don't like
to
> > write doc and I have better things to do... This is just an example
to
> > show you that *from the outside* the MockObjects.com suffers from
> > documentation.
> 
> OK. Let's collaborate. Can you outline what you think your developers
> will need?

Cool. Thanks! ATM I'm on holiday working on my book but I'll give you
more details once I'm back to work (in about 5 days).

Thanks
-Vincent

> 
> S.
> 

RE: [MO-java-dev] [VOTE] Release 0.08

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

> -----Original Message-----
> From: Tim Mackinnon [mailto:tim...@po...]
> Sent: 15 May 2003 01:04
> To: Vincent Massol; 'Mockobjects-Java-Dev'
> Subject: RE: [MO-java-dev] [VOTE] Release 0.08
> 
> Can you clarify what a 0.08 release means. Is this just package the
> current
> one (so we can then merge the branch) or is it just merge the branch?

It is the current CVS HEAD (no branch merge).

Thanks
-Vincent

> 
> Tim
> 
> > -----Original Message-----
> > From: moc...@li...
> > [mailto:moc...@li...]On Behalf
Of
> > Vincent Massol
> > Sent: 14 May 2003 15:40
> > To: 'Mockobjects-Java-Dev'
> > Subject: [MO-java-dev] [VOTE] Release 0.08
> >
> >
> > Hi all,
> >
> > I'd like to do the release for MockObjects 0.08 ASAP (please tell me
if
> > you'd rather do it! :-)).
> >
> > Thus I need to know:
> >
> > 1/ Do you agree to release?
> >
> > 2/ Do you agree to let me perform the release (i.e. I would be the
> > release manager)?
> >
> > 3/ Is anyone planning to add anything crucial for 0.08? If so now is
the
> > time to stand up... :-)
> >
> > 4/ Can all the developers who have contributed code to 0.08 please
> > modify the changes.xml file to explain what changes they have
brought
> > since version 0.07?
> >
> > I'm fixing some docs which haven't been touched for more than 2
years
> > for some of them... :-(
> >
> > Thanks
> > -Vincent
> >
> >
> >
> > -------------------------------------------------------
> > Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa
Clara
> > The only event dedicated to issues related to Linux enterprise
solutions
> > www.enterpriselinuxforum.com
> >
> > _______________________________________________
> > Mockobjects-java-dev mailing list
> > Moc...@li...
> > https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
> >
> > ---
> > Incoming mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
> >
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003

RE: [MO-java-dev] [New DynaMock] Why is there no match() method?

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

Ok. Here's use case:

I have in my code a call to queueConnection.close() (for example). I use
a Mock for QueueConnection. If I *don't* define either an expect*() or a
match*(), I get:

junit.framework.AssertionFailedError: mockQueueConnection: Unexpected
call: close()
Expected no methods
	at com.mockobjects.dynamic.Mock.invoke(Mock.java:95)
[...]

Which means to me that we have to define the behaviour for any method
called (and that there is no default behaviour assumed). Fine with me.
Then, I don't want to set an expectation on close() because this mock
setup is part of a general setup that I want to reuse across several
tests and some tests do call close(), some do not.

But there is no match() method. 

Basically I'd like to simply tell DynaMock that I don't care about this
close() method. ATM, I've tricked it, by using:

        mockQueueConnection.matchAndReturn("close", null);

But that seems like a hack (or even a DynaMock bug) to me.

Am I not thinking in the right direction?

Thanks
-Vincent

> -----Original Message-----
> From: Joe Walnes [mailto:jo...@tr...]
> Sent: 15 May 2003 09:03
> To: Vincent Massol
> Cc: moc...@li...
> Subject: Re: [MO-java-dev] [New DynaMock] Why is there no match()
method?
> 
> That's right. There's no reason to use match if you're not trying to
> setup a return value. You can still use expect in the same way to
setup
> return values which also have expectations on the method calls.
> 
> Vincent Massol wrote:
> 
> >Hi Joe,
> >
> >I thought the only difference between match*() and expect*() was that
> >expected methods were setting expectations that were verified when
you
> >call the verify() method on the mock?
> >
> >Also, expectAndReturn() does also setup return values, right?
> >
> >Thanks
> >-Vincent (Still confused by the difference between match*() and
> >expect*() :-))
> >
> >
> >
> >>-----Original Message-----
> >>From: Joe Walnes [mailto:jo...@tr...]
> >>Sent: 14 May 2003 21:38
> >>To: Vincent Massol; moc...@li...
> >>Subject: Re: [MO-java-dev] [New DynaMock] Why is there no match()
> >>
> >>
> >method?
> >
> >
> >>Vincent Massol wrote:
> >>
> >>
> >>
> >>>Hi,
> >>>
> >>>There is an expect() method (replacing the old expectVoid()), but
> >>>
> >>>
> >there
> >
> >
> >>>is no match() method. Any reason?
> >>>
> >>>
> >>>
> >>>
> >>The only use of match() is to setup return values - so it's not
needed
> >>for void methods.
> >>
> >>-joe
> >>
> >>
> >>
> >
> >
> >
> >
> 

Re: [MO-java-dev] [New DynaMock] Why is there no match() method?

[Joe W. <jo...@tr...>]

That's right. There's no reason to use match if you're not trying to 
setup a return value. You can still use expect in the same way to setup 
return values which also have expectations on the method calls.

Vincent Massol wrote:

>Hi Joe,
>
>I thought the only difference between match*() and expect*() was that
>expected methods were setting expectations that were verified when you
>call the verify() method on the mock?
>
>Also, expectAndReturn() does also setup return values, right?
>
>Thanks
>-Vincent (Still confused by the difference between match*() and
>expect*() :-))
>
>  
>
>>-----Original Message-----
>>From: Joe Walnes [mailto:jo...@tr...]
>>Sent: 14 May 2003 21:38
>>To: Vincent Massol; moc...@li...
>>Subject: Re: [MO-java-dev] [New DynaMock] Why is there no match()
>>    
>>
>method?
>  
>
>>Vincent Massol wrote:
>>
>>    
>>
>>>Hi,
>>>
>>>There is an expect() method (replacing the old expectVoid()), but
>>>      
>>>
>there
>  
>
>>>is no match() method. Any reason?
>>>
>>>
>>>      
>>>
>>The only use of match() is to setup return values - so it's not needed
>>for void methods.
>>
>>-joe
>>
>>    
>>
>
>
>  
>

Re: [MO-java-dev] First batch of questions on new Dynamic Mock API

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

Vincent Massol wrote:
> and 2/ willing to do so). Thus, the project manager has tasked me to
> write the missing MockObjects.com missing documentation for our
> project... *sigh* I have been postponing this as I also don't like to
> write doc and I have better things to do... This is just an example to
> show you that *from the outside* the MockObjects.com suffers from
> documentation.

OK. Let's collaborate. Can you outline what you think your developers 
will need?

S.

Re: [MO-java-dev] [VOTE] Release 0.08

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

Vincent Massol wrote:
> I'd like to do the release for MockObjects 0.08 ASAP (please tell me if
> you'd rather do it! :-)).
> 
> Thus I need to know:
> 
> 1/ Do you agree to release?

+1

> 2/ Do you agree to let me perform the release (i.e. I would be the
> release manager)?

+1

> 4/ Can all the developers who have contributed code to 0.08 please
> modify the changes.xml file to explain what changes they have brought
> since version 0.07?

frankly, I don't remember.

A big vote of thanks to Vincent for forcing us to get on with it.

S.

Re: [MO-java-dev] Need help on bugs+feature requests+

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

Vincent Massol wrote:
> 
> - There is one support request for DynaMock documentation
> (http://sourceforge.net/tracker/?atid=218189&group_id=18189&func=browse)
> and Steve is assigned to it. Steve, what's the status? Is that something
> you can commit now? If not, can it be pushed to 0.09?

This will have to wait, I'm afraid, especially as we're not quite stable.

> - We have 6 open bugs reports:
> http://sourceforge.net/tracker/?atid=118189&group_id=18189&func=browse
> Can those who have been active on this project lately tell me what needs
> to be done. Maybe some have already been correct? If not, is there any
> that should go in 0.08 or can we postpone them all to 0.09?
> 
> - There are 6 open patches
> (http://sourceforge.net/tracker/?atid=318189&group_id=18189&func=browse)
> . Again, are any important for 0.08? Is someone working on applying any?

I really don't know how important these are. Most of them are pretty 
small. Jeff would you like to comment?

S.

Re: [MO-java-dev] Web site generation question

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

Vincent Massol wrote:
> Thanks Jeff for the explanation! Now we need to know what we want:
> - remove the xdocs from CVS altogether?
> - or continue to use the xdocs (which are really simplified HTML) and
> simply perform a simple XSLT transform (using the Ant <style> task)?

There's a further issue. Joe has kindly set us up with a project wiki 
which should reduce some of the pain of keeping the site up to date.

My suggestion is to do whichever option is easiest for now, just to get 
the release out, and then think about what to do next.

Part of the problem is that I don't think anyone's active in any of the 
jakarta projects, so there's a (small) learning curve for working with 
the tools that, frankly, we haven't had time to climb. I'm also all for 
reducing dependencies on other infrastructure, given that it's such a 
small project.

S.

RE: [MO-java-dev] dynamic.CallBag which allows any number of calls

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

Barry -

Is this a question about the current head version vs. the branch version?

The new branch doesn't support this but its easy to add. ExpectedCall should
be copied (or subclassed not sure which) to CallAtLeastOnce and the method
matches reimplmented (e.g. return delegate.matches( methodName, args );
(When we get into the head version, ExpectedCall should be renamed to
CallOnlyOnce).  Subclass DefaultCallFactory and override createExpectedCall
to return your CallAtLeastOnce. Create a Mock with the new factory (or
subclass and have RelaxedMock the specifies the factory).

tim



> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Barry Kaplan
> Sent: 14 May 2003 16:09
> To: mockobjects
> Subject: [MO-java-dev] dynamic.CallBag which allows any number of calls
>
>
> I had a need for a CallBag, except I do not want to limit the number of
> calls. Mainly to support getters. Below is what I did. Is there another
> way? If not, could this be incorporated into the dynamic package?
>
> Notice that I had to override the field 'numcalls'. This is smelly. But
> I could not see any other way. And I'm not too happy about the class name.
>
> Also, I noticed that the comments in CallBag that the class was
> temporary, and would be pushed-up into CallSequence. If that is the
> case, I would like to see the ability to support unspecified number of
> calls.
>
> (Isn't there other support for unspecified number of calls in the Mock
> class?)
>
>
> ----
> package mockobjects;
>
> import com.mockobjects.dynamic.CallCollection;
> import com.mockobjects.dynamic.MockCall;
>
> public class CallSet extends CallCollection {
>
>      private int numCalls = 0;
>
>      public Object call(Object[] args) throws Throwable {
>          numCalls++;
>          int callIndex = findCallIndexAndCheckArguments(args, numCalls);
>          MockCall call = (MockCall)_expected_calls.get(callIndex);
>          _hasBeenCalled.add(callIndex, Boolean.TRUE);
>          return call.call(args);
>      }
>
>      protected int findCallIndexAndCheckArguments(
>              Object[] args, int callNumber) {
>          for (int i = 0; i < _expected_constraints.size(); i++) {
>              if (checkArguments(i, args)) {
>                  return i;
>              }
>          }
>          fail(errorMessage(args));
>          return -1;
>      }
>
>      public void verify() {
>          assertTrue(errorMessage(
>                  null), _expected_calls.size() <= numCalls);
>      }
> }
> ----
>
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003

RE: [MO-java-dev] Refactoring when using dymanic.Mock?

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

On a team of two pairs in a smallish project it was ok for us using
Eclipse... I havne't got larger figures to report yet. On the plus side, the
test first experience is much better.

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Barry Kaplan
> Sent: 14 May 2003 14:38
> To: mockobjects
> Subject: [MO-java-dev] Refactoring when using dymanic.Mock?
>
>
> What has been the experience (if any) of the use of refactoring tools
> when using the dynamic.Mock class? Specifically, the use of strings for
> specifying method names? With idea, I can ask to check for strings when
> performing a refactoring, but finding usages is out.
>
> I can't think of any other alternative though, so I though I would ask
> around.
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003

RE: [MO-java-dev] [VOTE] Release 0.08

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

Can you clarify what a 0.08 release means. Is this just package the current
one (so we can then merge the branch) or is it just merge the branch?

Tim

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Vincent Massol
> Sent: 14 May 2003 15:40
> To: 'Mockobjects-Java-Dev'
> Subject: [MO-java-dev] [VOTE] Release 0.08
>
>
> Hi all,
>
> I'd like to do the release for MockObjects 0.08 ASAP (please tell me if
> you'd rather do it! :-)).
>
> Thus I need to know:
>
> 1/ Do you agree to release?
>
> 2/ Do you agree to let me perform the release (i.e. I would be the
> release manager)?
>
> 3/ Is anyone planning to add anything crucial for 0.08? If so now is the
> time to stand up... :-)
>
> 4/ Can all the developers who have contributed code to 0.08 please
> modify the changes.xml file to explain what changes they have brought
> since version 0.07?
>
> I'm fixing some docs which haven't been touched for more than 2 years
> for some of them... :-(
>
> Thanks
> -Vincent
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003

RE: [MO-java-dev] Should CallSequence be called with new DynaMocks?

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

yes. The experience of the team I worked with was that the old way was
highly refactored but unintuitive.

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Vincent Massol
> Sent: 14 May 2003 12:41
> To: 'Mockobjects-Java-Dev'
> Subject: [MO-java-dev] Should CallSequence be called with new DynaMocks?
>
>
> Hi,
>
> With the old dyna mocks, I had:
>
> CallSequence sequence1 = new CallSequence();
> sequence1.expectReturn(new Constraint[] {C.eq(1)}, "FIRSTNAME");
> sequence1.expectReturn(new Constraint[] {C.eq(2)}, "LASTNAME");
> mockResultSetMetaData.expect("getColumnName", sequence1);
>
> I guess, the new canonical way of writing this is simply:
>
> mockResultSetMetaData.expectAndReturn("getColumnName", C.eq(1),
>     "FIRSTNAME");
> mockResultSetMetaData.expectAndReturn("getColumnName", C.eq(2),
>     "LASTNAME");
>
> Is this correct? (It works here but I'd like to make sure I'm doing it
> correctly :-)).
>
> Thanks
> -Vincent
>
>
>
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
>
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24/04/2003

RE: [MO-java-dev] [New DynaMock] Why is there no match() method?

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

Hi Joe,

I thought the only difference between match*() and expect*() was that
expected methods were setting expectations that were verified when you
call the verify() method on the mock?

Also, expectAndReturn() does also setup return values, right?

Thanks
-Vincent (Still confused by the difference between match*() and
expect*() :-))

> -----Original Message-----
> From: Joe Walnes [mailto:jo...@tr...]
> Sent: 14 May 2003 21:38
> To: Vincent Massol; moc...@li...
> Subject: Re: [MO-java-dev] [New DynaMock] Why is there no match()
method?
> 
> Vincent Massol wrote:
> 
> >Hi,
> >
> >There is an expect() method (replacing the old expectVoid()), but
there
> >is no match() method. Any reason?
> >
> >
> The only use of match() is to setup return values - so it's not needed
> for void methods.
> 
> -joe
> 

Re: [MO-java-dev] [New DynaMock] Why is there no match() method?

[Joe W. <jo...@tr...>]

Vincent Massol wrote:

>Hi,
>
>There is an expect() method (replacing the old expectVoid()), but there
>is no match() method. Any reason?
>  
>
The only use of match() is to setup return values - so it's not needed 
for void methods.

-joe

Re: [MO-java-dev] [VOTE] Release 0.08

[Joe W. <jo...@tr...>]

>
>
>>1/ Do you agree to release?
>>    
>>
>>2/ Do you agree to let me perform the release (i.e. I would be the
>>release manager)?
>>
+1, +1


-joe

RE: [MO-java-dev] Web site generation question

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

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...] On Behalf Of
> Jeff Martin
> Sent: 14 May 2003 18:15
> To: 'Mockobjects-Java-Dev'
> Subject: Re: [MO-java-dev] Web site generation question
> 
> On Wed, 2003-05-14 at 16:11, Vincent Massol wrote:
> > Hi,
> >
> > I've been trying the web site generation by going in doc/ and typing
> > "ant -f site.xml site".
> >
> > However, I was surprised to find that the generated HTML in out/
does
> > not come from the xdocs but from static HTML files in doc/html
> >
> > Could someone tell me what's the status and where the project is
going
> > for web site generation?
> 
> Basically we ran into problems with the xdocs stuff. As far as I know
> style book has never had an official release and there was several
> different incompatible version floating around at one time. This made
it
> very difficult for someone to just checkout the project and build the
> website.

Yes, stylebook is dead. But that shouldn't have been an issue. Just put
the stylebook jar in the project lib.

> 
> People were also saying they where put off editing the docs because of
> the unfamiliar syntax.

Never heard that one yet... :-) I'm surprised any jakarta project gets
any doc written at all in this case... :-)

> 
> Since all you really need for most of the site is a template to wrap
the
> menus around the pages it seemed fairly easy to use very simple html
> pages and a little bit of java to wrap them in the template.

Yes, that's the point of the xdocs... :-) They use a simplified HTML
syntax that has not style in it ;-)

As for the java part, are we reinventing XSL? :-) 

Over on Cactus land, we have a simple XSL stylesheet to transform our
xdocs to HTML and it works very nicely (check:
http://jakarta.apache.org/cactus). If you're interested in could make
our xdocs works with it?

> 
> This way we get away from the external dependencies & people can use
any
> old html editor to edit the pages.

Fine, but HMTL editors will almost always add lots of style elements and
are usually not able to conform to a given DTD... Better use a good XML
editor.

> 
> >
> > Would you like to move to Maven for building the mockobjects project
in
> > the future? If so, I can very quickly migrate the doc generation to
> > Maven and produce a site which looks like (http://maven.apache.org).
> >
> 
> Don't have to much of a problem with this if you want to do it. Though
> I'm getting lazy these days and resent having to install anything I
> can't just get from www.jpackage.org (can't see maven there yet), and
> I've looked on the maven site and can't see any mention of how you
> manage adhoc pages within the site or what syntax is used. You've
> probably got a much better handle on this than me.

Ok, what I can do if you're interested is simply bring the Cactus
stylesheets and adapt the xdocs to match.

Thanks Jeff for the explanation! Now we need to know what we want:
- remove the xdocs from CVS altogether?
- or continue to use the xdocs (which are really simplified HTML) and
simply perform a simple XSLT transform (using the Ant <style> task)?

Thanks
-Vincent

> 
> --
> 
> jeff martin
> information technologist
> mkodo limited
> 
> mobile: 44 (0) 78 55 478 331
> phone: 44 (0) 20 77 29 45 45
> email: jef...@mk...
> 
> www.mkodo.com
> 
> 73 Leonard St, London, EC2A 4QS. U.K

Re: [MO-java-dev] Web site generation question

[Jeff M. <jef...@mk...>]

On Wed, 2003-05-14 at 16:11, Vincent Massol wrote:
> Hi,
>=20
> I've been trying the web site generation by going in doc/ and typing
> "ant -f site.xml site".
>=20
> However, I was surprised to find that the generated HTML in out/ does
> not come from the xdocs but from static HTML files in doc/html
>=20
> Could someone tell me what's the status and where the project is going
> for web site generation?

Basically we ran into problems with the xdocs stuff. As far as I know
style book has never had an official release and there was several
different incompatible version floating around at one time. This made it
very difficult for someone to just checkout the project and build the
website.

People were also saying they where put off editing the docs because of
the unfamiliar syntax.

Since all you really need for most of the site is a template to wrap the
menus around the pages it seemed fairly easy to use very simple html
pages and a little bit of java to wrap them in the template.

This way we get away from the external dependencies & people can use any
old html editor to edit the pages.

>=20
> Would you like to move to Maven for building the mockobjects project in
> the future? If so, I can very quickly migrate the doc generation to
> Maven and produce a site which looks like (http://maven.apache.org).
>=20

Don't have to much of a problem with this if you want to do it. Though
I'm getting lazy these days and resent having to install anything I
can't just get from www.jpackage.org (can't see maven there yet), and
I've looked on the maven site and can't see any mention of how you
manage adhoc pages within the site or what syntax is used. You've
probably got a much better handle on this than me.

--=20

jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 55 478 331
phone: 44 (0) 20 77 29 45 45
email: jef...@mk...

www.mkodo.com

73 Leonard St, London, EC2A 4QS. U.K