> You could just do this: > <get src="http://${myhost}/commons.xml"; > dest="${user.home}/.ant/commons.xml" > usetimestamp="true"/> > <import file="${user.home}/.ant/commons.xml"/>
That's the first level of import I describe. But if common.xml refers (imports) to misc.xml also located at http://${myhost}/, but you must also <get> it explicitly, so you're breaking encapsulation (the build importing common.xml shouldn't need to know about the implementation of common.xml). You could make common.xml do the <get>+<import> dance as well, but then you're breaking transparency or location independence, where you need to change the build based on where it lives (jar, http, file system). When you think about it, HTML and XSL's href are not affected by this issue. True, these have been designed with location transparency from the get go, but in my mind that's the canonical model for import (linking/referring for HTML). Maybe a solution would be to introduce new href attributes for <import>, <property file>, <loadfile>, etc... which would obey what I call the "canonical" import model, and leave existing "file" or "location" attributes the way they are, i.e. dealing with file system files only. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
