WARNING: Comments below relate to the build process the way it currently is. After
Jon gets done, it will undoubtedly look quite different.
Stuart Roebuck wrote:
> On Friday, December 15, 2000, at 05:51 PM, Craig R. McClanahan wrote:
>
> > If you follow the recommended approach (create a "Jakarta" directory in your home
> > directory or wherever, and install all the project source distros inside it), this
>is a
> > given.
>
> Apologies, I didn't realise I had to download all of the Jakarta projects as one
>whole CVS checkout - I wrongly presumed that I could download the ones I was needing
>and that they stood on their own as well as together.
>
The README.txt file in the top-level directory of the source distribution identifies
the specifics of the dependencies, and the steps needed to set up your environment.
>
> > > 2. creating a "build" directory in the parent directory is not a problem or
>nuisance to
> > the management of other files on the hard-disc.
> >
> > If you follow the recommended approach (you will hear that a few times :-), this
>directory
> > ends up by default inside your "Jakarta" directory, completely segregated from
> > anything else on your disk.
>
> Where do I put my jakarta-ant sources that are running a different version than that
>required by cocoon and tomcat? If they are all part of one big project then I must
>assume that there are possible inter-relationships, and that some change I make to
>ant may break something in Tomcat or Cocoon. Or is there a way in which I can be
>certain that there are no dependencies?
>
If you want to use the "latest and greatest" Ant code, you would download the
jakarta-ant source repository parallel to jakarta-tomcat-4.0. If you want to use the
version of Ant 1.2 already installed in production on your development server, set the
ANT_HOME environment variable to point at it. See the comments at the top of
"build.sh" or "build.bat" for the similar mechanisms for finding all the other
dependent packages.
I think Jon is looking at using project-specific Ant properties files, rather than
environment variables, to accomplish pretty much the same goal.
>
> > > 3. different projects will create subdirectories of the "build" directory
>and these
> > subdirectory names will never clash, despite the huge number of open source
>projects in
> > existence.
> >
> > If the projects are really different, you should be building them someplace other
>than in
> > your "Jakarta" build directory. Then there are no clashes.
>
> Okay, I get the point, I really hadn't appreciated that the Jakarta directory was an
>absolute must do.
>
There's still the "religious" war over "build inside my source directory" versus
"build someplace else". I am of the latter camp -- partly because that's the way
Tomcat has built ever since it was first released to Apache, and partly because I've
grown to like it -- but if everyone wants it different, I'm game.
>
> > > If you have a directory of open source projects on your hard drive, lets call it
> > "opensource". Inside that you put all your open source work in separate checkout
> > directories: "jakarta-tomcat", "jakarta-ant", "argouml", "xml-cocoon", "omega",
> > "build", "somethingelse".
> > >
> > See above -- the recommended development approach is there for a reason.
>
> Perhaps if the separate references to the CVS archives for xml-cocoon and ant etc.
>were removed from the web site it would be clearer that you have to downloaded them
>all at once.
>
Are you thnking of particular web site references that are confusing and should be
fixed? I always follow the steps in the README.txt file (or equivalent) when setting
up to build a project I've never done before.
>
> > > You make them all and... disaster... All the jakarta projects have put their
>builds into
> > named directories inside the directory with my favourite "build" build tool -
>messing it
> > up with extra files that are nothing to do with it. Then "omega" completely wiped
>my build
> > directory when I did a clean build - it doesn't use subdirectories of "../build".
> > >
> > > I don't want to knock the neatness of keeping everything in a cvs checkout clean
>and
> > identical to the original, but what are the practical disadvantages of having the
>build
> > directory inside the checkout, especially if a 'clean' build cleans out the build
>stuff
> > automatically if you require?
> > >
> >
> > Try doing a "cvs commit" or "cvs update" in your source directory -- are the files
>marked
> > with "?" ones that I forgot to register with CVS or are they just outputs of the
>build
> > process? You have to think about that *every single time*.
>
> Yes, I can understand that being a frustration. I use a graphical CVS tool on MacOS
>X which shows the checkout directory hierarchically, so all I do is ignore the build
>directory when I'm looking. If your using command line tools, isn't there a facility
>for ignoring certain files that would allow you to ignore the "build" directory too?
>
Yep ... Sam pointed it out ... .cvsignore
>
> > And no, I am not willing to avoid this by doing a "build clean" every time I want
>to do a
> > check-in, and then waste the time to rebuild from scratch again. I will rebuild
>when *I*
> > want to or need to.
>
> I completely agree
>
> > >
> > > Being able to build outside of the checkout is an option some users may prefer,
>but I don't
> > think we should be providing this as a default unless we can be sure of the 3
>assumptions
> > above.
> >
> > The recommended development approach avoids the problems you have described,
>without
> > requiring building inside the source directory.
>
> But in effect, this *is* in the source directory, because the existence of the
>Jakarta directory is a requirement - it is therefore part of the source.
>
> > It also means you have control over which versions of dependent packages you use
>to build
> > Tomcat, even though you might be using a different version of Ant or an XML parser
>on some
> > other project.
>
> Okay, I think you've answered my earlier question. Am I right in saying that you
>are suggesting that I have multiple "Jakarta" directories for working on different
>versions of different parts of the jakarta project? If so I would have a "Jakarta
>(for ant work)" directory with the latest Ant CVS and whatever versions of everything
>else; and a "Jakarta (for Cocoon)" directory which would have Ant 1.2 and Tomcat 4m4
>lets say. Isn't this going to take up a lot of hard disc space, and be fairly
>unfriendly to people with slow internet connections?
>
Let me describe what I just had to do, to get a feel for why I like the current
approach.
Recently, there were security issues with Tomcat 3.1 that required creating a 3.1.1
release. Now, Tomcat 3.1 was dependent on the Ant that was current at that time, and
a whole bunch of other old stuff. But 3.2 (and 4.0) require the current Ant. What to
do?
I left my "Jakarta" directory (with the current 3.2 and 4.0 stuff in it) alone, and
created a separate one ("Jakarta-3.1"), in which I could download the version of Ant
that 3.1 depended on, grabbed the 3.1 sources for Tomcat, and built/tested/packaged it
-- all completely separate from my usual work environment. The relative references
work well in that scenario, because I organized things to keep mutually dependent
stuff together. Worked like a champ.
Ant in particular is a tool you will need to have available in multiple versions if
you are building lots of open source projects of different ages. The dramatic (almost
radical) deprecations and syntax changes between pre-1.0, 1.0, 1.1, and 1.2 will get
you in loads of trouble otherwise. To say nothing of the right XML parser, servletapi
classes, ...
The same scenario happens when you build other open source projects, too -- they all
have dependencies on particular versions of particular packages. Whether you build
inside the project directory or outside doesn't make any difference in that regard.
Personally, I find it easiest to organize top-level development directories around
mutually interdependent projects.
>
> Stuart.
>
Craig
