Bug 28403 - Floating attribute for import task
Summary: Floating attribute for import task
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.6.1
Hardware: Other other
: P3 enhancement with 1 vote (vote)
Target Milestone: ---
Assignee: Ant Notifications List
Keywords: PatchAvailable
Depends on:
Reported: 2004-04-15 08:13 UTC by johan.vromans
Modified: 2009-07-31 04:18 UTC (History)
0 users

Example implementation (2.96 KB, patch)
2004-04-15 08:15 UTC, johan.vromans
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description johan.vromans 2004-04-15 08:13:09 UTC
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:


If a file is find, the search is terminated.

An example implementation (diff to the 1.6.1. source tree) is attached.
Comment 1 johan.vromans 2004-04-15 08:15:50 UTC
Created attachment 11246 [details]
Example implementation
Comment 2 Steve Loughran 2004-04-15 09:23:08 UTC
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?
Comment 3 johan.vromans 2004-04-15 10:44:41 UTC
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
Comment 4 Jose Alberto Fernandez 2004-04-15 11:48:36 UTC
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. :-)
Comment 5 Steve Loughran 2004-04-15 14:22:10 UTC
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="../..;." />
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.
Comment 6 peter reilly 2004-04-15 15:36:04 UTC
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"/>

This could be a (standard) presetdef
<presetdef name="findimport">
       <pathelement path=".:..:../..:../../..:../../../.."/>
       <pathelement path="${user.home}/.ant/importfiles"/>
       <pathelement path="${ant.home}/.ant/importfiles"/>

<findimport file="common.xml"/>
Comment 7 Spindizzy_Wizard 2004-04-28 22:38:56 UTC
Check out 'bug' 22269.  It proposes adding '<fileset/>' to the import task.