Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 12516 invoked from network); 9 Jan 2003 15:33:41 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 9 Jan 2003 15:33:41 -0000 Received: (qmail 28687 invoked by uid 97); 9 Jan 2003 15:34:57 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 28671 invoked by uid 97); 9 Jan 2003 15:34:56 -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 28659 invoked by uid 98); 9 Jan 2003 15:34:55 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-Injected-Via-Gmane: http://gmane.org/ To: ant-dev@jakarta.apache.org Path: not-for-mail From: Costin Manolache Subject: Re: Improt task and project basedir Date: Thu, 09 Jan 2003 07:25:35 -0800 Lines: 87 Message-ID: References: <747F247264ECE34CA60E323FEF0CCC0C0F50A5@london.cellectivity.com> <3E1D326B.5020704@cortexebusiness.com.au> <3E1D3A7C.8000906@apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@main.gmane.org User-Agent: KNode/0.7.1 Sender: news X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N What about introducing a "BuildFile" in ProjectHelper - to store info about the file that is processed - including location and other info that we might need in future. The "resolve" can take into account the build file. ( and the helper would associate the UE with the BuildFile ) Seems clean. Regarding behavior - we should look at XSLT if applicable, but try to keep it simple. I think we can implement both choices ( basedir of the parent or basedir of imported file ), and we could make it customizable if really needed. I preffer using regular ant files and resolving based on the imported file location ( and basedir ). This would allow imported files to also work standalone - for example tomcat has 4-5 big components and a master build file that calls the smaller buildfiles. Costin Nicola Ken Barozzi wrote: > > Conor MacNeill wrote: >> Jose Alberto Fernandez wrote: >> >>> >>> This seem to be a not so simple issue. >> >> Indeed. As I've thought about it more, I wonder what we should be doing >> here. All the other tasks in the imported build file will be resolving >> relative to the basedir of the importing build, not the build in which >> they are defined. Is that good? I feel it may cause some problems, some >> unexpected behaviour. > > This is the reason why I asked to introduce the ant.file.projectname > property, that gives me the real path of the imported build. > >> Perhaps we need to examine the use cases for imported builds. I'm sure >> Nicola Ken will tell me some :-) > > :-) > > Centipede is based on this, because it makes it possible to use > predefined targets. > > What happens is that we use plugins called cents that are in fact jars > that contain a buildfile to import, some tasks, resources and classes. > These are versioned, and autodownloaded and autoimported. > > Here are some cents we have built: > http://www.krysalis.org/cents/cents/index.html > > More are in CVS. > >> If the imported files need to be designed apriori to be importable, > > Now it does, and I tend to think that it's not a bad thing. Similarly > buildfiles called by in many cases are designed to be called by a > parent. > >> then >> perhaps we should use a different container element for them. >> instead of and leave the basedir out of it. > > A normal project does not necessarily behave well if imported, because > of the basedir issue, but it can. Probably we should set the > ant.file.projectname property for the main buildfile too to fully > enable this. > > An imported file might not necessarily behave well if not imported, > since it might rely on prior properties being set. > > My point is that this solution should have the least possible complexity > for the users. That means that I'm not against , but I do > question the actual need of it. We already use with inherited > properties by default, and this ties the called file to the caller in > the same way; users have learned to expect this. > > To solve the problem we could add a importable="true" attribute to the > project. We can post a message that warns that it's not marked as > importable, and if the build fails and a file was imported, we can add > to the message a note that tells the user that the file that was > imported was not marked as importable. > > -- To unsubscribe, e-mail: For additional commands, e-mail: