Re: [Mockobjects-java-users] Directory structure

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

----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 22, 2001 11:14 PM
Subject: Re: [Mockobjects-java-users] Directory structure


> From: "Vincent Massol" <vm...@oc...>
> > Can I modify the directory structure to be :
> >
> > src
> >   |_ core
> >     |_ java
> >       |_ com/mockobjects/[...]
> >     |_ tests
> >       |_ com/mockobjects/[...]
> >     |_ examples
> >       |_ com/mockobjects/examples/[...]
> >
> > The core only contains the core classes (expectation lists, ...) and is
> > useful for projects like Mock Maker and others that do not need the mock
> > implementations. The distributable will be "mockobjects-java-core.jar"
>
> use 'src' instead of 'java'. It's all java.

yes, sure but there is already a src directory ... I am actually not
inventing here, just using a standard convention that I have seen all over
the place in open source java land.

>
> don't forget util. This library is unlikely to include examples as the
unit tests will cover that.

util is in java/com/mockobjects/util, right ?

>
> >   |_ standard (or a better name)
> >     |_ java
> >     |_ tests
> >     |_ examples
> > For the sub directories under the java directory, we have several
choices :
>
> > choice 1 : use the same package as the classes to mock. For example, the
> > mock for HttpURLConnection will be in the java.net package. the mock for
> > HttpServletRequest will be in javax.servlet.http, ... There is little
risk
> > that there will a name collision (as we name our classes MockXXX, but it
> > still exists)
>
> can't do that. clashes with VisualAge.

:(

>
> > choice 2 : use the java hierarchy but prefix by our domain name. For
> > example, MockHttpServletRequest will be in the
> > com.mockobjects.javax.servlet.http package
>
> too long

yes, I agree, but consistent and give us room ...

>
> > choice 3: keep the existing packages, i.e. no rules.
MockHttpServletRequest
> > will be in com.mockobjects.servlet
>
> Actually, this seems to work quite well as we tend to mock up only a
subset of the types from each library, and it makes the locations really
obvious. Also, it avoids excessive imports into test classes.

ok, we keep this one. We'll address the issue if it becomes one, later ...
:)

>
> An alternative might be mock.sql.*; mock.ibm.this.that.*
>
> > The "standard " directory will provides mock implementations for the
java
> > platform (java.* and javax.* packages). The distributable will be
> > "mockobjects-java-standard.jar"
>
> I would include the core classes in this jar to avoid excessive
classpaths, and not include the tests or examples.

ok, good idea.

>
> >   |_ extensions
> >     |_ atg
> >       |_ java
> >       |_ tests
> >       |_ examples
> >     |_ ...
> >
> > Each extension will be delivered as a separate jar. For example the atg
> > mocks will be delivered as : "mockobjects-java-atg.jar"
>
> We might want just to deliver the source code. We can't compile these
without the various 3rd party libraries and it could all get very
complicated.

ok, agreed, replace .jar by .zip

>
> > I'd like to do that ASAP ... so please hurry to comment if you don't
agree
>
> If you're going to make changes that put the connextra codebase at risk,
we'd better stick to the current packaging -- unless you can get agreement
from Tim.

As we won't change the package name, it won't put anyone at risk ...
-Vincent