At 08:58 AM 3/19/01, Craig R. McClanahan wrote:
>On Mon, 19 Mar 2001, Vincent Massol wrote:
>
> >
> > ----- Original Message -----
> > From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Sunday, March 18, 2001 11:30 PM
> > Subject: Re: Request go ahead for structural changes in CVS
> >
> >
> > >
> > >
> > > On Sun, 18 Mar 2001, Vincent Massol wrote:
> > >
> > > > Here follows the status (inline in the mail below). Please tell me if I
> > have
> > > > made any blunder and I'll correct it. Also, I have made some changes
> > that
> > > > are against standards/issues that have been approved/agreed upon (like
> > > > formatting of Ant build files, ...), please tell me and I'll
> correct it.
> > > > Thanks.
> > > >
> > > > ----- Original Message -----
> > > > From: "Vincent Massol" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Sunday, March 18, 2001 1:11 PM
> > > > Subject: Request go ahead for structural changes in CVS
> > > >
> > > >
> > > > > I'd like to have the go ahead for making the changes to the struts
> > > > directory
> > > > > structure, as mentionned in the thread "[PROPOSAL] Struts Source
> > Directory
> > > > > Structure".
> > > > >
> > > > > Namely, I'd like to commit the following changes that I have locally
> > on my
> > > > > computer (step 1) :
> > > > > - Move jakarta-struts/src/doc to jakarta-struts/doc
> > > >
> > > > done
> > > >
> > > Fine.
> > >
> > > > > - Move jakarta-struts/src/conf to jakarta-struts/conf
> > > >
> > > > done
> > > >
> > > Also fine.
> > >
> > > > > - Move build.xml, build.bat and build.sh to the new
> > jakarta-struts/build
> > > > > directory
> > > >
> > > > waiting for approval
> > > >
> > >
> > > I'm fine with the organizational change, and I modified the output of all
> > > the build processes to go to "target" instead of "build" now.
> > >
> > > One thing I've been toying with is how we can get out of having
> > > "build.sh" and "build.bat" scripts completely, and just use the
> > > "ant" script (from $ANT_HOME/bin) directly to run our builds. In
> order to
> > > set local environment variables, how about this:
> > >
> >
> > Yes, it would be nice to get rid as much as possible of batch files and
> > shell scripts.
> >
> > > * If there is a "build.properties" file in the directory you are
> > > running the build from (this will be "build" after the scripts
> > > are moved), load it at the top of build.xml.
> > >
> >
> > Is it possible to specify the java.class.path property in this file ? (I'd
> > like to have a different CLASSPATH for each project)
> >
>
>It ought to work (I've never tried it), but Ant 1.2 and 1.3 have very nice
>capabilities to build classpaths up dynamically, so that you can use
>different classpaths for different compilations if you need to.
I think the Ant approach would be preferable. That way, the
build.properties file just defines the locations of various things, and the
build file takes care of building the appropriate classpath for each target.
>On the more general point, however, I'd like to get to the point where we
>do not depend on anything in the developer's original CLASSPATH.
Absolutely. I see reliance on the user's classpath as one of the most
frequent causes of build problems.
> > > * The "build.properties" file would be unique to each developer's
> > > environment (mine will even be different on Linux and Windows :-),
> > > so it is *not* checked in to CVS.
> > >
> >
> > Fine, but we should provide a sample one to help know what to put
> inside. It
> > means we should also use lots of available tasks in the build.xml to verify
> > that all needed properties related to directories are set to correct paths.
> >
>
>Absolutely. IMHO the best place to document this is near the top of the
>build.xml file itself (which is where this file will be read if it
>exists). I've tried to be pretty copious in documenting what external
>properties that build-webapps.xml and build-webapp.xml depend on, for
>example. We'll also need to describe the (simple) syntax requirements.
>
>If we added a pointer to this in the README file, do you think that would
>be sufficient.
>
> > > * To avoid "?" messages from CVS, add "build.properties" to the
> > > appropriate ".cvsignore" file.
> > >
> > > Note that the dependency on Ant would be that you have $ANT_HOME/bin on
> > > your PATH in order to execute the builds by typing things like:
> > >
> > > ant compile.javadoc
> > >
> > > instead of saying
> > >
> > > ./build.sh compile.javadoc
> > >
> > > What do you think?
> >
> > fine. I'll try it on my computer. Although I hate going to DOS ... :) I
> > usually prefer having several batch files, even with a single line in
> it ...
> > This is actually what I have done for running the Struts build : one
> > directory above jakarta-struts, I have put the needed libraries and some
> > batch files ... :) I guess I'll have to change my way of doing things
> ... :)
> >
>
>I also look forward to trying out Antidote (GUI that is being developed
>inside the Ant project) and an Ant mode for emacs, so I can do these kinds
>of things directly.
>
> > >
> > > > > - Modified build.xml and build-webapps to support the above changes
> > > > >
> > > >
> > > > done
> > > >
> > > OK
> > >
> > > > > This will leave all the build output as it was before (except the
> test
> > > > > webapp which is no longer generated for the moment till I finish the
> > > > > integration with J2EEUnit).
> > > > >
> > > > > In a second step, I will add :
> > > > > - Some J2EEUnit test classes in src/test/org/apache/struts/action
> > > > > - new build-tests.xml and associated batch files in
> > jakarta-struts/build
> > > > > - new servlet engine configuration files in jakarta-struts/conf/test
> > to
> > > > > support automated J2EEUnit unit testing with several servlet engines
> > > > > - new environment variables to support testing with several servlet
> > > > engines
> > > > > (TOMCAT_HOME, CATALINA_HOME, RESIN_HOME, ...)
> > > > >
> > >
> > > Can we make a practice of defining the corresponding properties in a
> > > build.properties file, as in the discussion above?
> > >
> > > tomcat.home=xxxx
> > > catalina.home=yyyy
> > > resin.home=zzzz
> > >
> >
> > Yes.
> >
> > > > > Thanks for telling me quickly if I should go ahead or not (at least
> > for
> > > > step
> > > > > 1).
> > > > >
> > > > > Also I have noticed that when editing the build*.xml files in my
> > UltraEdit
> > > > > all spaces and tabs are disorganized and make the text difficult to
> > read.
> > > > I
> > > > > think we should standardize on a tab value of 4 (for example) and in
> > our
> > > > > editors replace tabs by spaces.
> > > > >
> > > >
> > > > done. Tell me if I have done something wrong
> > > >
> > >
> > > Looks good so far.
> > >
> > thanks.
> >
> > > > > Thanks.
> > > > > Vincent.
> > > >
> > > > Vincent.
> > > >
> > > >
> > >
> > > Craig
> > >
> >
> > Vincent
> >
> >
>
>Craig
--
Martin Cooper
Tumbleweed Communications
