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:

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

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

* 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?

> > - 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

> > 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.
> > Vincent.
> 
> Vincent.
> 
> 

Craig


Reply via email to