I guess it all boils down to the fact that it just looks nicer to be able
to have the subproject say "these are the packages I depend on", and then
have the included build.xml handle all the dirty work of building the
classfiles and such. It makes it cleaner and easier to understand when
someone has to add a new subpackage. All they have to know is:
- I include the main build.xml file
- I define what my source files are (I haven't gotten to this part yet)
- I define what other packages I rely on
- I create a target that depends on the "init" target
- I'm now good to go
This way, the person adding the new package doesn't have to know where the
packages they rely on are located, and such things.
Rob Seeger
At 11:38 AM 9/26/01 -0700, you wrote:
>--- Robert Seeger <[EMAIL PROTECTED]> wrote:
>> The classpath will be used in conjunction with any java tasks. The basic
>> concept is that the main build.xml (the one included by all the sub
>> projects) sets up the classpath to a union of:
>> - directories and jars that every project will use
>> - directories and jars that the current subproject will use
>
>But rather than listing the package elements for the sub-project classpath
>and passing those off to something else to generate a classpath from, why
>not just create the sub-project's classpath using <path>, and combine that
>with the generic classpath? Or am I missing something that would prevent
>you from doing that?
>
>Diane
>
>=====
>([EMAIL PROTECTED])
>
>
>
>__________________________________________________
>Do You Yahoo!?
>Get email alerts & NEW webcam video instant messaging with Yahoo!
Messenger. http://im.yahoo.com
>
========================================
Robert Seeger
Network Engineer
Nortel Networks
Telephone: (518)237-2087
Pager: (800)SKY-8888 Pin#1264792
Fax: (518)237-4190
Email: [EMAIL PROTECTED]
Address: 224 5th Ave, Apt#2
Lansingburgh, NY 12182
========================================
