Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 35210 invoked from network); 15 Jan 2003 00:06:16 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 15 Jan 2003 00:06:16 -0000 Received: (qmail 25991 invoked by uid 97); 15 Jan 2003 00:07:40 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 25975 invoked by uid 97); 15 Jan 2003 00:07:39 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 25963 invoked by uid 98); 15 Jan 2003 00:07:39 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3E24A5F6.20009@chalko.com> Date: Tue, 14 Jan 2003 16:06:14 -0800 From: Nick Chalko User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ant Developers List Subject: Re: Import use cases, basedir behavior and target, property prefixing References: <3E2494BF.8060803@ct42.de> In-Reply-To: <3E2494BF.8060803@ct42.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Claas Thiele wrote: > There are at least 2 use cases of import: > (1) providing reusable functionality > - providing ant build file fragments by framework distributors > - using parts of a buildsystem in a cross project manner. > (2) linking subprojects in a large project > > Both partially contrary in terms of basedir handling. > > For (1) imported functionality would be used in the context of the > main project. Basedir should always the basedir of the main project. Agree > > For (2) imported functionality would be used in the context of the > import (the subproject). The basedir should be set to import context. I do not think (2) is a usecase for import. I think it is better handled by the "ant" task. > > proposed behavior: > > If basedir is set in project element it means: basedir is set in > context to the file containing the project element (as before). This > is used for subproject handling. > > If basedir is not set it will be inherited from the importing project. > Thats for module usage. > > May be downward compatible (basedir not set in main project is always > '.'). > > Sometimes it is necessary to address resources in the context of an > import. For that reason the basedir (context) of each imported project > should be accessible from everywhere. A property can be instanciated > with name like imports..basedir while importing a > project. imports.basedir should be responsible for main (root) > projects basedir so root context is accessible from everywhere. we already have ant.file. Which is the complete path to the imported file. The task will already strip off the file name part. > > Implementation proposal for basedir handling: > Each target is executed in a context holding the basedir. If basedir > is set in an imported project a new context is instanciated and used. > Otherwise the existing context is used. So basedir is hold by a > context not the project. > > > Proposed behavior for target and property name prefixing > > Each target and property name and id (forgot something?) should be > seen as in a namespace. The namespace is formed by the containing > project and named by the containing project name. Inside a project the > namespace (prefix) is implicit and can be omitted. Referencing targets > and properties outside the containing project the namespace is used. > The resulting name or id is constructed by namespace, delemiter, local > name. > The root resources can be referenced using an empty namespace (lokal > name with preceding delimiter). > Concrete examples at http://ct42.de/en/ch02s05.html (Except the root > of imported files is named 'module'): > Namespace collisions by independent developed imports can be prevented > by using naming conventions like for java packages (preceed url of > provider of import). > > > Proposed implementation: > It is done for targets in ANTModule (http://ct42.de/en/ch02.html) in a > special ProjectHelperImpl while parsing the project file. ANT > integration hints are given (http://ct42.de/en/ch02s07.html). > Additionally the namespace resolving functionality provided by the > projecthelper must be used for all property names, id's and target > names and dependencies while initialising this objects. > > In my opinion importing and providing namespace related functionality > should be placed in the projecthelper not in a task. > So the existing order problem for top level elements is solved > automatically. > > > > ------------- > Claas Thiele > > http://ct42.de > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: -- Nick Chalko Show me the code. Centipede Ant + autodownloadable build plugins + needed jars autodownload. http://krysalis.org/centipede --------------------------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: