Menu
▾
▴
mockobjects-java-dev
|
From: Vincent M. <vm...@oc...> - 2001-07-29 22:38:55
|
Hi, I would like to propose a change in the license. Would you agree to move from Mozilla license to an Apache license (APL) ? The reason I have is simply that it is easier to change license early in a project rather than later and it seems Cactus and mockobjects might integrate/share/benefit from each other more easily if the mockobject project was under an Apache license (because Cactus is already using that license as an Apache project). For example, Cactus could use mockobjects as its implementation for a MO strategy ... What do you think ? Thanks -Vincent Massol |
|
From: Vincent M. <vm...@oc...> - 2001-07-30 09:54:41
|
I have removed the forum feature from the mockobjects SF developers' page as we have now switched to a mailing-list mechanism. Note: There were only a few messages posted on the forum and none contained information important enough to republish it to the mailing-list. However, the messages posted to the forum are not lost and the forum can be reactivated at any time by an admin if need be. Thanks -Vincent |
|
From: Vincent M. <vm...@oc...> - 2001-07-30 10:56:35
|
In <root>/src/core, there is jar file (mo_java1_compatibility.jar) containing sources. What is it and why are the sources in it not expanded, like the rest ? Thanks -Vincent |
|
From: Steve F. <st...@m3...> - 2001-08-01 08:36:17
|
----- Original Message ----- From: "Vincent Massol" <vm...@oc...> To: <moc...@li...> Sent: Monday, July 30, 2001 11:58 AM Subject: [Mockobjects-java-dev] What is mo_java1_compatibility.jar ? > In <root>/src/core, there is jar file (mo_java1_compatibility.jar) > containing sources. What is it and why are the sources in it not expanded, > like the rest ? > They're some extra classes to allow Tim to run the MO library on java 1.1.8, that should be picked up in the classpath. The default library runs in Java 1.2+ Steve |
|
From: Vincent M. <vm...@oc...> - 2001-08-01 09:56:02
|
----- Original Message -----
From: "Steve Freeman" <st...@m3...>
To: <moc...@li...>
Sent: Wednesday, August 01, 2001 9:37 AM
Subject: Re: [Mockobjects-java-dev] What is mo_java1_compatibility.jar ?
>
> ----- Original Message -----
> From: "Vincent Massol" <vm...@oc...>
> To: <moc...@li...>
> Sent: Monday, July 30, 2001 11:58 AM
> Subject: [Mockobjects-java-dev] What is mo_java1_compatibility.jar ?
>
>
> > In <root>/src/core, there is jar file (mo_java1_compatibility.jar)
> > containing sources. What is it and why are the sources in it not
expanded,
> > like the rest ?
> >
>
> They're some extra classes to allow Tim to run
> the MO library on java 1.1.8, that should be
> picked up in the classpath. The default library
> runs in Java 1.2+
>
Ok. Then 2 things :
* Why are they not expanded as the other java source files ? We could have
the following directory structure:
<root>/src/framework
|_ share (or java)
|_ com ...
|_ jdk1.1
|_ com ...
|_ examples
|_ com ...
|_ tests
|_ com ...
<root>/src/extensions
|_ vaj
|_ share (or java)
|_ examples (if applicable)
|_ tests (if applicable)
|_ eziba
|_ atg
|_ ...
* Why don't we use the collection classes for JDK 1.x instead of writing our
own (http://java.sun.com/products/javabeans/infobus/) ?!
or
* Why do we use JDK 1.2 specific classes and not the generic classes
(Vector, Hashtable, ...) ?
> Steve
-Vincent
|
|
From: Vincent M. <vm...@oc...> - 2001-07-30 11:33:32
|
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 ?
Thanks
-Vincent Massol
|
|
From: Vincent M. <vm...@oc...> - 2001-07-30 11:42:10
|
Building the mockobjects project requires : - a JDK installed - Ant installed with the needed tasks : stylebook (version 2), junit - depending on what mocks we want to build, some external jars (like servlet.jar if we want to build the servlet mocks, ...) In order to facilitate building the mockobjects project, I propose to provide on the developer web site (i.e. SF) a prepackaged zip containing Ant with the needed tasks already in there. This is what I have done on the Cactus project and it's been very successful. Ok ? -Vincent Massol |
|
From: Vincent M. <vm...@oc...> - 2001-07-30 11:50:52
|
----- Original Message ----- From: "Vincent Massol" <vm...@oc...> To: <moc...@li...> Sent: Monday, July 30, 2001 12:43 PM Subject: [Mockobjects-java-dev] Prepackaged Ant version > Building the mockobjects project requires : > - a JDK installed > - Ant installed with the needed tasks : stylebook (version 2), junit > - depending on what mocks we want to build, some external jars (like > servlet.jar if we want to build the servlet mocks, ...) > > In order to facilitate building the mockobjects project, I propose to > provide on the developer web site (i.e. SF) a prepackaged zip containing Ant > with the needed tasks already in there. This is what I have done on the > Cactus project and it's been very successful. > More precisely, I propose a new package named mockobjects-tools (in the notes area we mention that it contains tools to help build the project for developers and that it is not needed for end users) and put a file named : mockobjects-java-ant-YYYYMMDD.zip > Ok ? > -Vincent Massol |
|
From: Vincent M. <vm...@oc...> - 2001-07-30 11:58:42
|
I have entered the following project description on SF (http://sf.net/projects/mockobjects). "Generic unit testing framework and methodology for testing any kind of code" Tell me what you think. If you have a better description, feel free to post it here. Thanks -Vincent |
|
From: Vincent M. <vm...@oc...> - 2001-07-30 14:20:06
|
Hi, 1/ Why is there 2 directories : 'vaj' and 'visualage' in the extensions directory ? 2/ What is eziba ? 3/ Do we want to generate a separate jar file per extension, like one for atg, one for visualage, one for eziba, ... ? My answer would be yes and it seems it is the approach currently followed as proved by the released packages on SF Thanks -Vincent |
|
From: Vincent M. <vm...@oc...> - 2001-07-30 17:24:41
|
I'd like to know if we want to make them be the same thing or if we want to make www.mockobjects.com a portal site regrouping anything that's related to Mock Objects : articles, tools, books, ... and have the mockobjects project simply be a possible implementation (in java to start with) ? Thanks -Vincent |
|
From: Vincent M. <vm...@oc...> - 2001-07-30 17:52:40
|
----- Original Message ----- From: "Vincent Massol" <vm...@oc...> To: <moc...@li...> Sent: Monday, July 30, 2001 6:26 PM Subject: [Mockobjects-java-dev] www.mockobjects.com and the mockobjects project ... same ? > I'd like to know if we want to make them be the same thing or if we want to > make www.mockobjects.com a portal site regrouping anything that's related to > Mock Objects : articles, tools, books, ... and have the mockobjects project > simply be a possible implementation (in java to start with) ? > I have drafted the main page of the Mock Objects web site (in <root>/doc/xdocs/index.xml). Please tell me what you think. Also we need to find a better logo. The problem with the mock turtle logo is that it being black and white it does not lend well to resizing and is not clear and sharp at all when in small ... But being too big it eats almost all the page and the page titles look way too small in that big space ...:) Ideally we would need a logo that takes more space horizontally than vertically. > Thanks > -Vincent -Vincent |
|
From: Vincent M. <vm...@oc...> - 2001-07-30 17:57:48
|
Hi, I have added a todo/roadmap page : <root>/doc/xdocs/todo.xml The goal of this page is twofold : * first it shows to user what is left to be done before being able to release the following version, * second it lets everyone know who is working on what (I know there is also a task assignment tracker in SF that we may use for that. This is just a first draft. We may wish to remove the volunteer column later on and use this tracker later on - we'll see). So, if you think about a task that needs to be done, please update this file. This will be our preferred way of deciding what tasks are left and for what version to implement them. Thanks -Vincent |
|
From: Vincent M. <vm...@oc...> - 2001-07-30 18:12:50
|
Same as for the todo, there is now a changes page (<root>/doc/xdocs/changes.xml) that contain the history changes for all versions including the current one in CVS. This is a coarse-grained changelog and is intended mostly for users so that they know what's new in the latest release. For example, if we modify a file because a comment was wrongly aligned, it doesn't have to go in this changelog (it will be in the CVS changelog anyway). however, if have fixed a bug or modified namings in the code or ... then it needs to be there. Please remember to always edit this file when you make a change. Otherwise it is difficult and lengthy to find back what has been done (though it is possible using CVS). It also shows us what's been done so far on the current version, so it is a good indicator of progress. Thanks -Vincent |
|
From: Vincent M. <vm...@oc...> - 2001-07-31 16:33:48
|
We now have a fully functional build process which does :
- jar
- documentation (local web site + javadoc)
- site generation
- unit tests
- dist : build the distributables. Currently only one :
mockobjects-0.01.zip containing
|_ lib
|_ mockobjects.jar
|_ doc
|_ local web site + javadoc
Try it and tell me if you like it !
TODO: Depending on the answer to previous emails, we need to know what we do
with the extensions and samples. For samples, I guess we can put them in
mockobjects-0.01.zip.
-Vincent
|
|
From: Steve F. <st...@m3...> - 2001-08-01 08:41:21
|
----- Original Message ----- From: "Vincent Massol" <vm...@oc...> To: <moc...@li...> Sent: Monday, July 30, 2001 3:21 PM Subject: [Mockobjects-java-dev] Why 'vaj' and 'visualage' in extensions dir + others > Hi, > > 1/ Why is there 2 directories : 'vaj' and 'visualage' in the extensions > directory ? History. Haven't had the time to merge them. > 2/ What is eziba ? A stub JDBC library. It's a nice job and I would like to support it. > 3/ Do we want to generate a separate jar file per extension, like one for > atg, one for visualage, one for eziba, ... ? My answer would be yes and it > seems it is the approach currently followed as proved by the released > packages on SF > Yes. We may not be able to build them all because of dependencies on libraries that we don't have handy. Steve |
|
From: Vincent M. <vm...@oc...> - 2001-08-01 10:21:26
|
----- Original Message ----- From: "Steve Freeman" <st...@m3...> To: <moc...@li...> Sent: Wednesday, August 01, 2001 9:41 AM Subject: Re: [Mockobjects-java-dev] Why 'vaj' and 'visualage' in extensions dir + others > > ----- Original Message ----- > From: "Vincent Massol" <vm...@oc...> > To: <moc...@li...> > Sent: Monday, July 30, 2001 3:21 PM > Subject: [Mockobjects-java-dev] Why 'vaj' and 'visualage' in extensions dir > + others > > > > Hi, > > > > 1/ Why is there 2 directories : 'vaj' and 'visualage' in the extensions > > directory ? > > History. Haven't had the time to merge them. I have added it as a task in the todo. > > > 2/ What is eziba ? > > A stub JDBC library. It's a nice job and I would > like to support it. How is it going to fit with the SQL mock implementation ? Is it doing the same ? Why the name 'eziba' ? What do you mean to support it : is it maintained by someone else, if so where ? Here ? When you're going to write a tutorial for JDBC testing how is it going to fit as compared with the SQL mock impl. ? Is it an alternative ? > > > 3/ Do we want to generate a separate jar file per extension, like one for > > atg, one for visualage, one for eziba, ... ? My answer would be yes and it > > seems it is the approach currently followed as proved by the released > > packages on SF > > > > Yes. We may not be able to build them all because > of dependencies on libraries that we don't have > handy. > ok fine. > Steve -Vincent |
|
From: Vincent M. <vm...@oc...> - 2001-08-01 17:38:02
|
As Tim and Steve gave their agreement, the license has been changed to the Apache Software License (APL) as suggested in previous email. If anyone sees a problem with this, please contact us. It means that all versions prior to version 0.01 are still under the MPL license (this is irrevocable) but any new version (i.e. the coming 0.01) will be under the APL license. Thanks to everyone -Vincent |
|
From: Vincent M. <vm...@oc...> - 2001-08-01 17:48:29
|
This is a proposal for a short term roadmap : * By the end of the week (i.e. before 5/8), release the first version of the user web site and have mockobjects.com point to it. * Release version 0.01 around the 15/8. It will contain (at least) : - user web site with documentation which explains - what are MockObjects - how to use them - the goal of the project - future roadmap - MockOjbects style and naming conventions - good javadoc comments for existing classes - clean up of classes (like vaj and visualage, ...), add license info - code aligned with naming conventions - finalized build process (still need to finalize directory structure + manage examples and extensions) At that time (on the 15th), we'll do some advertising on several well chosen mailing lists (JUnit, all xprogramming lists, Cactus) and web sites (theserverside, javalobby, jguru, freshmeat, javaworld - I am not sure we'll be accepted but we can try -). Any comment (I'm sure there will be :-) ) ? Thanks -Vincent |
|
From: Steve F. <st...@m3...> - 2001-08-01 08:41:24
|
----- Original Message ----- From: "Vincent Massol" <vm...@oc...> To: <moc...@li...> Sent: Monday, July 30, 2001 1:00 PM Subject: [Mockobjects-java-dev] Project description > I have entered the following project description on SF > (http://sf.net/projects/mockobjects). > > "Generic unit testing framework and methodology for testing any kind of > code" > > Tell me what you think. If you have a better description, feel free to post > it here. There was one which seems to have got lost. I'll try to dig it up again. Steve |
|
From: Vincent M. <vm...@oc...> - 2001-08-01 10:15:25
|
----- Original Message ----- From: "Steve Freeman" <st...@m3...> To: <moc...@li...> Sent: Wednesday, August 01, 2001 9:40 AM Subject: Re: [Mockobjects-java-dev] Project description > > ----- Original Message ----- > From: "Vincent Massol" <vm...@oc...> > To: <moc...@li...> > Sent: Monday, July 30, 2001 1:00 PM > Subject: [Mockobjects-java-dev] Project description > > > > I have entered the following project description on SF > > (http://sf.net/projects/mockobjects). > > > > "Generic unit testing framework and methodology for testing any kind of > > code" > > > > Tell me what you think. If you have a better description, feel free to > post > > it here. > > There was one which seems to have got lost. I'll > try to dig it up again. > Can you also validate the description I have put in the web site doc (index.xml). I'd like to have the mockobjects web site live tomorrow (it will be accessible by clicking on 'home page' on SF developer's page). Could you also change the configuration on your domain name provider so that there is no banner displayed at the top of the page when the user type www.mockobjects.com ? And change the link to be http://mockobjects.sourceforge.net instead of http://sourceforge.net/projects/mockobjects (in preparation for the mockobjects web site) ? Thanks -Vincent |
|
From: Steve F. <st...@m3...> - 2001-08-01 08:41:20
|
----- Original Message ----- From: "Vincent Massol" <vm...@oc...> To: <moc...@li...> Sent: Monday, July 30, 2001 12:43 PM Subject: [Mockobjects-java-dev] Prepackaged Ant version > Building the mockobjects project requires : > - a JDK installed > - Ant installed with the needed tasks : stylebook (version 2), junit > - depending on what mocks we want to build, some external jars (like > servlet.jar if we want to build the servlet mocks, ...) > > In order to facilitate building the mockobjects project, I propose to > provide on the developer web site (i.e. SF) a prepackaged zip containing Ant > with the needed tasks already in there. This is what I have done on the > Cactus project and it's been very successful. > > Ok ? Fine. We should make clear which versions of ant and junit we're using. Steve |
|
From: Vincent M. <vm...@oc...> - 2001-08-01 10:12:19
|
----- Original Message ----- From: "Steve Freeman" <st...@m3...> To: <moc...@li...> Sent: Wednesday, August 01, 2001 9:40 AM Subject: Re: [Mockobjects-java-dev] Prepackaged Ant version > > ----- Original Message ----- > From: "Vincent Massol" <vm...@oc...> > To: <moc...@li...> > Sent: Monday, July 30, 2001 12:43 PM > Subject: [Mockobjects-java-dev] Prepackaged Ant version > > > > Building the mockobjects project requires : > > - a JDK installed > > - Ant installed with the needed tasks : stylebook (version 2), junit > > - depending on what mocks we want to build, some external jars (like > > servlet.jar if we want to build the servlet mocks, ...) > > > > In order to facilitate building the mockobjects project, I propose to > > provide on the developer web site (i.e. SF) a prepackaged zip containing > Ant > > with the needed tasks already in there. This is what I have done on the > > Cactus project and it's been very successful. > > > > Ok ? > > Fine. We should make clear which versions of ant > and junit we're using. > For me, this shouldn't be a problem and should work with all versions of Ant and Junit ! For example, Cactus runs with any version of Ant and JUnit. Some asserts have been deprecated in JUnit. That's fine, we'll have some warnings when we build. When JUnit removed the methods, we'll also update and then at that time, we'll say that we only support versions of JUnit greater than such. That's why we don't deliver Ant and JUnit as parts of the mockobjects distributable : to let users use their own versions - most of the users will already have Ant and/or JUnit installed and we don't want to multiply the number of different versions they have on their hard disk. Better work with any ! However for those who are not familiar with Ant, we provide a prepackaged zip to help them. > Steve -Vincent |
|
From: Steve F. <st...@m3...> - 2001-08-01 08:41:20
|
----- 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. 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. Steve |
|
From: Vincent M. <vm...@oc...> - 2001-08-01 10:08:22
|
----- 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
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X