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.
> > 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?
> > 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.
> > 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.
> > 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?
> 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?
Stuart.
-------------------------------------------------------------------------
Stuart Roebuck [EMAIL PROTECTED]
Lead Developer Mac OS X, Java, XML, etc.
ADOLOS http://www.adolos.com/
