Craig,
Thanks for this. If my analysis is correct I think our preferences are very similar,
but we started with different viewpoints:
1. I saw Tomcat as a stand-alone project dependent on other stand-alone projects : you
saw Tomcat as part of one interdependent Jakarta project.
2. I saw the build directory as being completely outside the project by default and
saw this as a 'problem/side-effect' : you saw the build directory as being
out-of-the-way-of sub-project directories but nevertheless still within the overall
jakarta project as specified in the README.
So, the differences of view, if my analysis is right, revolve around whether or not
Tomcat, Ant, Cocoon, etc, should be see as stand-alone projects which happen to
sometimes rely on one another, or parts of one interdependent project.
I prefer the idea of smaller stand-alone projects because I think they are easier to
'get into' as an outsider. But as long as folk know which way to look at things I
guess it works either way.
Cheers,
Stuart.
On Friday, December 15, 2000, at 08:00 PM, Craig R. McClanahan wrote:
> 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
>
>
>
-------------------------------------------------------------------------
Stuart Roebuck [EMAIL PROTECTED]
Lead Developer Mac OS X, Java, XML, etc.
ADOLOS http://www.adolos.com/
