ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Ant Wiki] Update of "NewAntFeaturesInDetail/Import" by Jon Cox
Date Fri, 09 Oct 2009 20:14:26 GMT
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?'''

Mime
View raw message