See comments intermixed.
> > > > 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.
I have to agree with Craig on this one. I think developers should be able to
choose their own tools, rather than have the decision made for them. I
should be able to decide how Ant is configured on my system, and which
servlet implementation I build against.
On a slightly different tack, I also wouldn't want to see the download size
for struts balloon dramatically because all the external software is now
internal. People should only have to download what they need. (For example,
when I download the nightly build, I really don't want another version of
Ant or the servlet API implementation.)
> > 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
> :-(.
I use Ant like this all the time, actually, for work projects as well as
Struts. The only issue with Win98 is that you have to define ANT_HOME and
friends using the ugly short form of the path (e.g. use C:\Java\jakart~1.2
instead of C:\Java\jakarta-ant-1.2).
> > > > 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.
Yes, this is my preference too. It is also how I have organized our projects
at work.
> 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.
Although I realise that the API would be (or should be!) the same, I prefer
to build against the implementation that is used by the container I am going
to deploy against. It just feels "safer". Of course, with something like
Struts, there is no single target platform, but it would seem to me that
having different developers using different implementations would ensure
better exposure.
> 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.
Then I guess I'm in that same minority. :-}
--
Martin Cooper
Tumbleweed Communications
