Vincent,
See intermixed.
Vincent Massol wrote:
> 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.
>
I totally agree with the "plug and play" download for Struts *users*. That's
the same reason that a binary distribution of Tomcat contains everything you
need that can be legally included.
But, that is slightly different from the requirements to *build* Struts --
which, of course, would include scripts for creating the "plug and play"
download for users. IMHO, it should be possible to build the "plug and play"
download with different combinations of packages to suit different needs. All
of this requires relatively more complexity in the Struts build process itself
-- but it need not compromise the usability of what typical users are
downloading.
>
> > 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.
>
Yep ... just point ANT_HOME at wherever you've installed Ant, and it is supposed
to work.
Unfortunately, I've had problems getting the bin/ant.bat script to work on Win98
:-(.
>
> > >
> > > 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 ?
>
Note that the below comments relate to packaging JAR files in the *source*
repositories of various projects -- as stated above, I have no problem with the
idea of creating a "Struts Development Kit" if people find that useful.
<soapbox>
It's definitely a problem if you want to rebuild from source -- you have to
remember to use the right version of ant for the right subpackage.
It's definitely a problem if you try to combine packages that use incompatible
versions of dependent packages -- and this happens much more because of the
habit of "everything you need" in CVS repositories.
It's definitely a problem because this habit encourages developers to not worry
about interoperatbility.
</soapbox>
>
> >
> > > 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...
>
That makes sense ... let's go with that.
>
> > >
> > > 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.
>
There is one other interesting issue with the servlet API classes in particular
-- it is legal for a servlet container to provide their own implementation of
these classes, so the one from Tomcat may or may not actually *run* in a
different servlet container, although you should not have any problems just
compiling against it.
>
> >
> > 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 ...
>
As stated above (and is also obvious if you look at the Tomcat build process
:-), I don't have a problem with external build dependencies. But I am
definitely in the minority.
>
> > >
> > > 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
>
Turbine (and others) use "target" where you have "out" -- I'm OK with either.
>
> > >
> > > 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
>
Yes, you definitely need to use the same package names for testing package
private stuff.
>
> > >
> > > 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 ... :)
>
+1 :-)
>
> > >
> > > Thanks.
> > > Vincent.
> >
> > Craig
> >
>
> Vincent.
Craig
