Humm now that brings up an interesting question. I see what your saying... See the source tree is built up of many projects as well as a common package for reused classes. So I would then adopt a hybrid of those ideas if I was to follow that I have 1 build.xml for each project. Since projects are developed by different teams (sometimes at the same time). But I would also need a build for the common as well as one to build the whole package at the root. So here is the issue. At any point in time any of these classes might be further developed by anyone, once it is released, for support reasons. Am I assuming too much to have to require them to edit the "projects" build.xml file and use the knowledge that typing ANT in a subpackage of the projects package (made for organizational purposes) would read that projects build.xml file and compile their class... Also the logic for compiling a class in a subpackage would need to be different then the logic used in the main dir of the project. When a new comer is requested to add a class to the project they would need to specify the path from the project trees root. I thought it might be easier to have a simple rule that the build file in the current directory compiles the classes in "that" directory. And just leave it at that... so that one has more freedom to change package subpackages (subdirectories). Since this is a corporate project its 80+ classes minimum and I can perhaps see one wanting to change the name of one of the subpackages while the project is being developed... The other though would be if one wanted to move classes from one level to another, instead of having to retype lots of path names, you would just cut and paste the <antcall> tag sections into the local build.xml... Though I see merit in having one build file... But under the nature of the compile environment... I don't know if it would actually make things more complicated in the long run... humm, this will require more thought. Thanks, I will have to hunt down that thread in the archives. -Ben Don Taylor wrote: > There's another thread that's been going on in this list that goes over > the merits of having a "global" build where a single build.xml file > builds everything versus a "local" build where each package has its own > build.xml file and the whole thing is driven by a global build.xml > which is essentially a director. It's a holistic vs. reductionistic > argument. > > It really depends on why you have multiple packages in the first place. > If they're just ways of organizing your project, then build everything > in a global build.xml. If they're stand-alone packages that are put > into jars that can or are being used for other projects then they > should have their own build.xml and your project's build.xml should > just ensure the package is up-to-date. That's how I like to approach > builds. >
begin:vcard n:Stocum;Ben tel;home:442-1316 tel;work:383-3510 x-mozilla-html:FALSE url:http://www.paychex.com org:Paychex, Inc;Enterprise Development adr:;;911 Panorama Trail S.;Rochester;NY;14625-2396; version:2.1 email;internet:[EMAIL PROTECTED] title:Developer Lv 1 fn:Ben Stocum end:vcard
