Re: [Mockobjects-java-dev] Deliverables and organization of the src tree

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

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 01, 2001 9:39 AM
Subject: Re: [Mockobjects-java-dev] Deliverables and organization of the src
tree


>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@oc...>
> To: <moc...@li...>
> Sent: Monday, July 30, 2001 12:35 PM
> Subject: [Mockobjects-java-dev] Deliverables and organization of the src
> tree
>
>
> > Hi,
> >
> > I'd like to propose the following src directory hierarchy
> >
> > src
> >   |_ framework
> >     |_ com
> >       |_ ...
> >   |_ tests
> >     |_ com
> >       |_ ...
> >   |_ extensions
> >     |_ com
> >       |_ ...
> >   |_ examples
> >     |_ com
> >       |_ ...
> >
> > Where :
> >
> > * framework : the core classes + mock implementations for the standard
> > J2SE/J2EE classes, i.e. the standard APIs making the Java platform
> (servlet,
> > taglib, io, sql, ...)
> > * tests : the core classes unit tests. Note that there is no need for
test
> > classes for the mock implementations themselves as they don't contain
> logic
> > (just getters/setters)
> > * extensions : mock implementations for APIs that are _not_ part of the
> Java
> > platform (J2SE/J2EE), like VisualAge for Java Tools API, Struts, ATG
> > proprietary classes, ...
> > * examples : comprehensive examples showing how to use the mockobject
> > framework and also acting as functional tests for the mockobject
> framework.
> >
> > Can I go ahead with this and make the little needed modifications and
put
> a
> > README file that explains this ?
>
> shouldn't 'framework' be 'core'?
>
> I'm not sure about the package name for the
> tests. These days, I've been replacing
> com.one.two... with test.one.two... We need
> separate packages for tests so we can separate
> them in VisualAge.

1/ Why do you need separate packages for tests inside VAJava ? Why do you
want to separate them in VisualAge ?
2/ This a very very standard approach agreed by 99,9999999% of the people I
have spoken to ! I would hate not to do it simply because VAJava is having a
problem with that ... :)

>
> I'm not sure, but we may need to distinguish
> between core mocks (such as io) and J2EE mocks
> (such as servlets) which require extra jars to
> compile. The other extensions (such as atg)
> should definately be separate.
>

Which is why I changed 'core' to 'framework'. For me, the core are the
mockobject core classes (Expectation classes, interfaces, ...), whereas the
standard framework is both the core + some standard mock implementations.
The extended frameworks are the standard framework + extensions.

I don't really see a problem with having servlet mocks in the standard
framework even if they are not used. I think it is better than having
hundreds of little jars : one for servlet, one for JNDI, one for SQL, ....
Also, I don't think siez will be a problem as mock implementations are
really small. Also, there is no problem for users if they don't have the
servlet.jar in their classpath for instance as they are not going to use the
servlet mock. It won't cause any problem.

However, I'd like to propose the following directory structure which look
more consistent to me :

<root>/src/framework
  |_ share (or java)
    |_ com ...
  |_ jdk1.1 (if needed - see other mail)
    |_ com ...
  |_ examples
    |_ com ...
  |_ tests
    |_ com ...

<root>/src/extensions
  |_ vaj
    |_ share (or java)
    |_ examples (if applicable)
    |_ tests (if applicable)
  |_ eziba
  |_ atg
  |_ ...

So that each part can have it's own examples and tests. It better
compartiments everything and will lead to an easier Ant build script (We'll
be able to factorize).

> Steve
-Vincent