----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 19, 2001 5:58 PM
Subject: Re: Request go ahead for structural changes in CVS
>
>
> 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.
>
> 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.
>
I completely agree. I have spent the day today changing the way I was using
Ant for J2EEUnit itself. Your suggestion works very well so far :
- I use a build.properties file
- I have installed Ant and have put all jars needed for it's core and
optional tasks in %ANT_HOME%/lib
- I have properties for the other jar files defined in my build.properties
file
> > > * 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.
>
I think it would be fine but we also need to provide a
build.properties.sample file that gives an example (the same way it is done
in the jakarta-ant sources;they provide a ant.properties.sample file)
> > > * 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
>
Vincent
