----- 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)
> * 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.
> * 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 ... :)
>
> > > - 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
