| Summary: | Floating attribute for import task | ||
|---|---|---|---|
| Product: | Ant | Reporter: | johan.vromans |
| Component: | Core tasks | Assignee: | Ant Notifications List <notifications> |
| Status: | NEW --- | ||
| Severity: | enhancement | Keywords: | PatchAvailable |
| Priority: | P3 | ||
| Version: | 1.6.1 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | other | ||
| Attachments: | Example implementation | ||
Created attachment 11246 [details]
Example implementation
It's an interesting idea, but one that worries me as it could be confusing. I'd be happier with the option of giving a path to import, with the first one found in the path being picked up. What do you think of that option? That would be nice as well, but it would require fixed locations (hard-wired path names) which is what we try to avoid. However, in most cases, an import path of ".:..:../..:../../..:../../../.." would be sufficient to emulate the "float" behaviour to the extent needed. Do you envision the path setting as an import task attribute, or as a property setting? If we add a search-path for imports, please make sure it is not an attribute but a <path/> element (and of course a corresponding "pathref" attribute). This would be not only for consistence, but it will also allow writing custom Path implementation that does what the original user wanted (i.e., it will report path elements that go all the way back to the root of the filesystem). So could easily get the best of both worlds. :-) I'd go for a path/pathref. My use case for it would be in smartfrog.org's build, where we have separate components that we want to redist (with source), but which all depend on ..\..\common.xml that they import. So I'd have the release script copy that file into the base dir of the archive, then have <import file="common.xml"> <path path="../..;." /> </import> and have it picked up in the parent dir first. This is why it would be more powerful than a simple 'float' attr; it would be more like the include path used in C/C++ inclusion. The path nested element is pretty powerful, it also
covers my use-case:
<import file="common.xml">
<path path=".:${user.home}/.ant/importfiles:${ant.home}/importfile"/>
</import>
This could be a (standard) presetdef
<presetdef name="findimport">
<import>
<path>
<pathelement path=".:..:../..:../../..:../../../.."/>
<pathelement path="${user.home}/.ant/importfiles"/>
<pathelement path="${ant.home}/.ant/importfiles"/>
</path>
</import>
<presetdef>
<findimport file="common.xml"/>
Check out 'bug' 22269. It proposes adding '<fileset/>' to the import task. |
To increase the usefulness of the import task, I propose to add an optional boolean attribute "float" with the following semantics, if set: if the named file to be imported cannot be found, retry one level higher in the file hierarchy, and so on. This makes it possible to put common files (with common properties, taskdefs etc.) somewhere higher in the file tree, so that all build scripts can load them without actually knowing the exact path to the file. This is quite similar to the --find command line option, although in this case the complete name of the file is used instead of just the final part. For example, when the following import <import file="x/common.xml" float="true"/> were used from /a/b/c/d/build.xml, the following file names would be tried: /a/b/c/d/x/common.xml /a/b/c/x/common.xml /a/b/x/common.xml ... If a file is find, the search is terminated. An example implementation (diff to the 1.6.1. source tree) is attached.