Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Ant Wiki" for change 
notification.

The "NewAntFeaturesInDetail/Import" page has been changed by Jon Cox:
http://wiki.apache.org/ant/NewAntFeaturesInDetail/Import?action=diff&rev1=6&rev2=7

  
  
  <import> is a boon to multi-project builds because it lets you keep all 
dependencies in a single DAG  (c.f: "Recursive Make Considered Harmful"),
+ in a multi-project build.   
+ 
- in a multi-project build.   For example,  suppose build.xml does an <import> 
of two projects named "x", and "y", and that both "x" and "y" 
+ For example,  suppose build.xml does an <import> of two projects named "x", 
and "y", and that both "x" and "y" 
- have targets named  "moo".   Any target in any of the projects can make an 
explicit reference to target "x.moo"  or "y.moo" in its depends clause. 
+ have targets named  "moo".   Any target in any of the projects can make an 
explicit reference to target "x.moo" or "y.moo" in its depends clause. 
  This feature is wonderful, but is woefully under-documented, and has least 
two nasty flaws:
  
-   *  Names of targets within a project aren't bound tighter than names 
external to a build file.   Therefore, if project "x" is imported first, then 
project "y",
+   *  Names of targets within a project aren't bound tighter than names 
external to a build file.
+      Therefore, if project "x" is imported first, then project "y", and a 
target in "y" depends
-      and a target in "y" depends on "moo", then ant will interpret that as 
"x.moo",  NOT "y.moo".  That's particularly scary when you consider that the 
world of
+      on "moo", then ant will interpret that as "x.moo",  NOT "y.moo".  That's 
particularly scary 
+      when you consider that the world of targets that can potentially be 
imported is huge and a
-      targets that can potentially be imported is huge and a dependency 
hijacking could be both silent and in a remote file elsewhere in a big build. 
+      dependency hijacking could be both silent and in a remote file elsewhere 
in a big build. 
  
-   *  Targets in the top-level don't get a magical  
''projectname''.''targetname'' alias.   You can only refer to them by their 
unadorned  ''targetname''.
-      This is evil because what happens if a target in the top level gets 
moved elsewhere?   At that point you're right back to the first problem 
mentioned
-      of being subject to silent dependency hijacking.   As of Ant 1.7, you 
cannot refer to the targets in the main build file explicitly, so there's no 
-      workaround for this one other than knowing about it & being careful. 
+   *  Targets in the top-level don't get a magical  
''projectname''.''targetname'' alias.  
+      You can only refer to them by their unadorned  ''targetname''.
+      This is evil because what happens if a target in the top level gets 
moved elsewhere?
+      At that point you're right back to the first problem mentioned of being 
subject 
+      to silent dependency hijacking.   As of Ant 1.7, you cannot refer to the 
targets 
+      in the main build file explicitly, so there's no workaround for this one 
other than
+      knowing about it & being careful. 
  
  ----
  '''How does an imported file load a resource relative to itself?'''

Reply via email to