Craig,
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 24, 2001 10:44 PM
Subject: Re: PROPOSAL - Testing Framework
> Vincent Massol wrote:
>
> > I am now looking at Struts in order to write the test suite (I have only
> > looked at build.bat and build.xml so
> > far ...) and I have notice the following details that may need to be
> > corrected/improved :
> >
>
> Hello Vincent,
>
> Sorry for the slow response ... I was really focused yesterday on getting
the
> beta out. Now we can start planning next steps.
>
> >
> > 1- In build.bat, the CP variable does not define an XML parser.
> > %ANT_HOME%\lib\jaxp.jar and %ANT_HOME%\lib\parser.jar should be added.
Or,
> > is that voluntarily because you want to leave the choice to the
developer to
> > choose his one jaxp compliant parser ? Personnaly, I prefer to force it
to a
> > choice that will always work. I prefer to leave my CLASSPATH always
empty
> > because otherwise it creates lots of problems when you switch from one
> > project to another ...
> >
>
> My preference has always been to allow people to choose their own tools --
such
> as their own version of Ant, their own XML parser, their own servlet API
> version, and so on -- rather than force these decisions. After all,
Struts will
> be used in applications that have all manner of dependencies on different
> versions of these things.
>
Yes, I understand that but my point is only to make it easy for person who
download struts and want to try it. I'm always trying to make the software I
write as much "plug and play" (or should I say "download and run") as
possible. But this does not preclude power users to use other versions of
these libraries.
> On Ant in particular, I would actually prefer us to run Ant via
> "$ANT_HOME/bin/ant" (Unix) or "%ANT_HOME%\bin\ant.bat" (Windows). That
way, we
> can let Ant itself worry about the changing directory structures required
by
> different versions of Ant. In addition, modern versions of "ant" and
"ant.bat"
> let you define system properties via "~/.antrc" (Unix) or
"%HOME%\antrc_pre.bat"
> and "%HOME%\antrc_post.bat" (Windows).
>
I didn't know Ant was supposed to be run like this. It actually makes sense
if you consider Ant as an application that you install on your system
somewhere and then you call it (from there) with different build
configurations.
> >
> > 2- In build.bat, the CP variable adds %ANT_HOME%\lib\ant.jar (and
> > optional.jar) but in the jakarta-ant distribution that I got using CVS,
the
> > ant.jar and optional.jar are generated and put in dist\lib.
> >
>
> Switching to $ANT_HOME/bin/ant will take care of this kind of thing.
>
> >
> > 3- Is that an Apache choice not to bundle the needed external jars
within
> > your own project ?
>
> Different Apache subprojects do it differently -- this is my choice (and
I'm
> probably in the minority here). I use quite a few open source projects,
and the
> number of copies of ant.jar and xerces.jar on my hard drive is pretty
> disgusting.
That's true, but is it a problem ?
>
> > I would tend to prefer to bundle ant
> > jars and servletapi jars for Struts because (a) they are only used to
build
> > struts, not for runtime and (b)otherwise the building of struts will
fail or
> > succeed depending on the state of these other projects, thus you might
get
> > lots of posts on the mailing list from persons trying to build Struts
but
> > failing just because they have a bad version of Ant for instance (I
speak
> > from experience as for J2EEUnit I tried several Ant release and I can
tell
> > you they were not all working, far from that, and I had to struggle to
find
> > the good one. At least I know that the one I bundle is going to work
with no
> > problem and from time to time I upgrade it. In other words I certify my
app
> > to work with such version. However if the enn developer want to use a
> > newer/older version, he is free to try it ...). Thoughts ? (Sorry if
this
> > way of doing it has already been discussed at length ... :( )
> >
>
> It hasn't been discussed on STRUTS-DEV, so it's probably worth talking
about.
>
> How do folks feel about this? Was the pain of having to download the
> prerequisite packages worth the ability to use whatever versions you
preferred?
>
> >
> > 4- build.xml need more comments, better formatting and some minor
additional
> > refactorings (to my opinion). Am I allowed to do that ?
> >
>
> Yes. Once we agree on a path, any of the docs or build scripts are fair
game,
> along with the code :-).
>
> >
> > 5- What do you think about creating a build directory where you put the
> > files that are needed to run the build of struts. They would be :
build.xml,
> > build.bat, all Ant jars (that's only if you agree with point 3 of course
...
> > :) ), maybe some other batch files to help start other targets from
Windows.
> > The output of the build will go in a directory named out/ for example (I
> > have always found the name build/ for the output to be confusing. It
means
> > "a build" but also "to build" ...)
> >
>
> I personally prefer the build.xml and associated scripts to be in the
top-level
> directory so you do not have to go hunting for them.
>
> Currently, the 'build" directory is an *output* of the Struts build
process,
> rather than an input. We'd have to change that (for example, some
subprojects
> use "target" for their destinations). In your scenario below, it looks
like
> this should be changed to "out".
>
I like to have a build directory where I put the ant jars + batch/sh files.
You have only one for the moment but the number will grow with support of
several servlet API. Moreover, for those on work on Windows, it is good to
have several batch files named after the target they execute so we can start
them by double-clicking on them. Then we'll have a batch file/sh for
automatically running all the tests in all servlet engines, ... That's why I
like to have a dedicated build directory...
> >
> > 6- If you agree on point 3, creating a lib directory at the top level to
put
> > the servletapi jar would be a good idea.
>
> Which version?
This depends on whether you want to support both API 2.2 and 2.3. If yes,
you could bundle both and just append a different prefix like 22 and 23.
Yes, I know I also prefer to try to keep the original name but it's not that
bad. Or use two directories like lib\servletapi22 and lib\servletapi23.
>
> Right now, Struts requires only servlet 2.2 / JSP 1.1 APIs, but my daily
work on
> Tomcat 4.0 requires me to use the servlet 2.3 / JSP 1.2 servlet.jar file.
This
> is the kind of problem you run into by forcing a choice on the developer
:-).
>
Then you can have 2 build files, one to build stuts with Servlet API 2.2 and
one for Servlet API 2.3. You'll need that someday, when you'll have to
support both API and you'll have some code specific to 2.2 and other
specific to 2.3
> > . Also I need to put the j2eeunit +
> > junit jars. Putting them in lib/ would be a good idea I think.
> >
>
> As opposed to saying "go build these projects yourself and provide an
> environment variable pointing at them"? Yah, OK, I guess -- a "lib"
directory
> it is.
>
:) Otherwise we increase the number of dependencies with external projects
you have to download ...
> >
> > 7- Why do you have a conf/ directory under src ? Wouldn't you prefer it
to
> > have
> > at the top level (or is it a Jakarta requirement) ? Something like :
> >
>
> Conceptually, I think of these files as part of the source code, but it's
no big
> deal one way or the other to me.
>
Yes, I agree but everything in jakarta-struts is part of the source, right ?
I don't really care either. Only that (example, share, test, unit) really
seem to go together because they are code whereas conf/, doc/ are other
subjects. Here is my preferred structure (updated) :
jakarta-struts
|_ out (generated by the build script)
|_ dist
|_ build
|_ (support batch/sh files) + ant jars (if we agree on that) + build.xml
(if ok)
|_ conf
|_ unit
|_ doc
|_ src
|_ example
|_ share
|_ test
|_ unit
|_ web
> >
> > jakarta-struts
> > |_ out (generated by the build script)
> > |_ build
> > |_ conf
> > |_ doc
> > |_ src
> > |_ example
> > |_ share
> > |_ test
> > |_ web
> >
>
> You would need an additional output directory, "dist", for the target of
the
> "distribution" build.
>
Yes, see above
> >
> > 8- I'd like to use the src/test/ directory to put the struts unit tests.
> > What is the already existing test directory ? Was it done for that
purpose ?
> >
>
> It has the Java sources for the struts-test.war web application, in the
same way
> that "src/example" has the Java sources for the "struts-example.war" web
app.
>
> I would prefer not to eliminate this web app, because it offers a quick
and
> dirty way to exercize the various custom tags as they are being build
> interactively. However, it would not bother me to change the name.
>
> How about directory "src/unit" for the unit tests (and, correspondingly,
package
> name "org.apache.struts.unit.*" when you are not required to have the unit
tests
> in the same package as the class being tested)?
>
ok see above. For the package, I usually prefer to use the same packages as
the classes under tests (for protected method test). Having 2 types of
packages seem a bit artificial to me
> >
> > 9- I'd like to create a test/ subdirectory un conf/ where I'll put all
the
> > configuration files needed for the struts unit tests. Is that ok?
> >
>
> If we use "src/unit" for the unit test sources, it should probably be
> "conf/unit" for consistency. But I am fine with a subdirectory here.
>
ok
> >
> > 10- The strategy I have followed with J2EEUnit for it's tests was to run
the
> > tests in the out/ directory, i.e. not deploy to the servlet engine
install
> > directory. I like to control the files that I generate. By being located
> > under out/, they (a) are easy to clean up, (b) do not affect any other
> > webapp running on my system, (c) I can use the setting I want for my
servlet
> > engine for the tests without affecting the main config of my servlet
engine.
> > I would suggest the following directory hierarchy :
> >
> > jakarta-struts
> > |_ out
> > |_ tests
> > |_ tomcat-3.2
> > |_ conf
> > |_ webapps
> > |_ work
> > |_ tomcat-4.0
> > |_ ...
> > |_ resin-1.2
> > |_ ...
> > |_ ...
> > |_ conf
> > |_ test
> > |_ j2eeunit.properties
> > |_ tomcat
> > |_ testserver-3.2.xml
> > |_ testserver-4.0.xml
> >
>
> Sounds reasonable -- the only recommended change would be to use "unit"
rather
> than "test" as a directory name if we choose *not* to eliminate the
current
> struts-test webapp.
>
ok for unit
> >
> > 11- Does Struts support only one servlet api at a time (like the 2.2
one) or
> > is it your plan to support several, like 2.2 and 2.3 ?
> >
>
> Right now, all of Struts is based on the servlet 2.2 / JSP 1.1 APIs. At
some
> point in the future, I would like to start building optional capabilities
that
> require 2.3 / 1.2, but for the foreseeable future we cannot really make
that a
> requirement.
>
> Fortunately, the 2.3 / 1.2 servlet API classes are "forwards compatible",
so
> that you can generally compile against them and still run on a 2.2/1.1
servlet
> container, as long as you avoid any of the new method calls.
>
> >
> > Please feel free to discard anything that I have said that does not fit
your
> > plan. I understand that I am new here ... However, I just wanted to let
you
> > know my thoughts in case I bring forward something that can improve
Struts.
> >
> > Tell me what you think of these and tell me how I have to proceed for
> > building the test suite ? Do I
> > change the files and send the to you by email ? What can I apply from
the
> > above mentionned points ? Is there a CVS branch that I
> > should work on instead of the main one ?
> >
>
> What I'd like to do is the following:
>
> * Propose you and Rob as committers (see separate message) according
> to the standard Jakarta policies and practices, so you can both have
> write access to the CVS repository.
>
> * Make the organizational changes that come out of the above discussion
> in the current HEAD branch, to be completed prior to 1.0-beta-2. (I
don't
> anticipate the need for more than one more beta cycle, but we'll see
what
> bug reports show up).
>
> * At that point, make the 1.0 code a branch in the repository, so we can
> make the HEAD branch available for starting on 1.1 related stuff.
>
> Does that sound like a plan?
>
Thanks ! That's great ... Let's get the work done ... :)
> >
> > Thanks.
> > Vincent.
>
> Craig
>
Vincent.
