Bug 29251 - [patch] add @url to <import> task
Summary: [patch] add @url to <import> task
Status: RESOLVED FIXED
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.7.0
Hardware: All All
: P3 enhancement with 1 vote (vote)
Target Milestone: 1.8.0
Assignee: Ant Notifications List
URL:
Keywords: PatchAvailable
: 35718 41701 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-05-27 18:05 UTC by Dave Brondsema
Modified: 2009-11-14 23:28 UTC (History)
2 users (show)



Attachments
implements @url support for <import> task (5.85 KB, patch)
2004-05-27 18:06 UTC, Dave Brondsema
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Brondsema 2004-05-27 18:05:43 UTC
This patch will allow you to specify <import
url="http://${myhost}/commons.xml"/> as an alternative to using a file
attribute.  This is very useful to keeping lots of scripts using the latest
version of an import.
Comment 1 Dave Brondsema 2004-05-27 18:06:21 UTC
Created attachment 11682 [details]
implements @url support for <import> task
Comment 2 Matt Benson 2004-06-01 16:09:53 UTC
The main reason this has not been implemented, IIRC, goes back to the statement 
in the documentation that "for every imported file, Ant adds a property that 
contains the path to the imported buildfile. With this path, the imported 
buildfile can keep resources and be able to reference them relative to its 
position."  What is that value using this patch?
Comment 3 Dave Brondsema 2004-06-01 18:28:37 UTC
Would it be acceptable if when importing from a url, all references in the
imported file were resolved relative to the main buildfile?  For example, if
/home/me/a.xml imported http://site/b.xml and b had a <propertyfile
file="foo/bar.properties">, ant would load /home/me/foo/bar.properties (not
http://site/foo/bar.properties).
Comment 4 Matt Benson 2004-06-01 18:41:47 UTC
I think, according to the documentation, that what you propose is the behavior 
you will see anyway.  The issue I mentioned is fairly minor--it is not how file 
references will be resolved that is in question, for that is specified in the 
documentation of <import>.  The only uncertainty is how the path to the 
imported file will be set up.  For example, we might declare that it will be 
unspecified in this usage, and woe to the user who mixes the two 
expectations... I don't know, just throwing a possibility out there.
Comment 5 Jose Alberto Fernandez 2004-06-02 09:32:57 UTC
Alternatively, we could think of having a file cache (in tmpdir) or specified 
in the import, where we put the fetched file for the sake of the build. One 
advantage of that is that we can use http's ifmodified requests to accelerate 
the build process.
Comment 6 Benjamin Burgess 2005-11-29 15:21:30 UTC
*** Bug 35718 has been marked as a duplicate of this bug. ***
Comment 7 Benjamin Burgess 2005-11-29 15:24:13 UTC
(In reply to comment #0)
> This patch will allow you to specify <import
> url="http://${myhost}/commons.xml"/> as an alternative to using a file
> attribute.  This is very useful to keeping lots of scripts using the latest
> version of an import.

You can already do this:

<get src="http://${myhost}/commons.xml" dest="${user.home}/.ant/commons.xml"
usetimestamp="true"/>
<import file="${user.home}/.ant/commons.xml"/>
Comment 8 Stefan Bodewig 2009-11-04 20:38:44 UTC
svn revision 832990 allows importing of resources that are either FileProvider or URLProvider - it still needs documentation, that's why I don't close this issue right now.
Comment 9 Stefan Bodewig 2009-11-05 05:43:00 UTC
*** Bug 41701 has been marked as a duplicate of this bug. ***
Comment 10 Stefan Bodewig 2009-11-14 23:28:17 UTC
documented with svn revision 836334