struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Request go ahead for structural changes in CVS
Date Mon, 19 Mar 2001 16:58:39 GMT


On Mon, 19 Mar 2001, Vincent Massol wrote:

> 
> ----- Original Message -----
> From: "Craig R. McClanahan" <craigmcc@apache.org>
> To: <struts-dev@jakarta.apache.org>
> 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" <vmassol@octo.fr>
> > > To: <struts-dev@jakarta.apache.org>
> > > 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.

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.

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



Mime
View raw message