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.
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).
>
> 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.
> 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".
>
> 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?
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 :-).
> . 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.
>
> 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.
>
> 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.
>
> 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)?
>
> 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.
>
> 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.
>
> 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.
> Vincent.
Craig
