ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: ant 1.5.4 : Import
Date Sat, 26 Jul 2003 03:42:17 GMT
I answer Jose Alberto below about his specific points, but here are a
few others that were discussed:

1) Imported file build names

   Actually, I don't care about the name of the imported file at all,
   and as a build writer, I wish I didn't have to give the project a
   name at all! When I import for example a template/generic build file
   to modify just what's necessary for my project, I couldn't care less
   about the name that imported file has. What I care about is the
   file name and location of it, not its project name. The top-level
   (or importing, or concrete) project does have a name (it's my project
   after all), but why should the generic template need a name? Finding
   name is difficult, and I prefer not doing it at all when not

   `-> Make the project name of imported build files optional

   Now, assigning a name to files I import to resolve conflicts between
   them, that I care greatly about! Of course, one should be forced to
   assign such names as long as there are no conflicts. The build would
   simply fail if conflicts arised eventually, and one can then either
   a) resolve the conflicts by modifying the imported files
   b) resolve the conflicts by renaming/prefixing on the fly the
      imported targets.

   I personally would prefer doing (a), but (b) can be handy one day.

   With renaming though, arises the issue of nesting and scoping.
   Consider A imports B & C, B imports D & E: A renames B to avoid
   conflicts with C, and B itself reanmed E to avoid conflicts with D.
   Should A need to be aware of B's renaming? I think not, or we open
   pandora's box!

   When a build file B imports other build files with naming (D & E),
   only non-conflicting targets from D and E are exported/visible to
   build files importing B, as well as B's own targets (both the ones
   it adds to be build 'API', or the ones it overrode from B & E).
   In other words, the renaming is scoped to B itself, the one doing the
   renaming, and build files higher up never see these names. They were
   used to resolve the conflicts at one given import level. As in real
   code, B could choose to expose targets from D or E it overrode by
   exposing them under a different name, explicitly exporting them.

   `-> All this to say that import renaming is an implementation detail
       of a given build file, aimed at resolving conflicts. It should
       never be visible outside the context of the build file that does
       the renaming!!!

2) IDE Integration

   I agree with Steve that's its important. We for example use IDEA's
   Ant integration, and always build using the build file, and never
   the IDE.

   I'm not sure whether IDE's would choke on a different top-level
   tag than <project>, and digest more easily a new attribute. Would
   have to be tested for IDEA, NetBeans, Eclipse, and co. I guess.

3) What does ${basedir} mean in an imported build file?

   Well I think I go at length in my answer to Jose Alberto, but I'll
   just say again that it should resolve to the top level's build file

   Imagine I want to write a generic build file for all my projects,
   enforcing the fact that the Java sources should be in a src/ dir
   relative to the basedir. In my imported file, I'd simply write

   <javac srcdir="src" destdir="classes" />

   Wherever this generic build file is imported from, the <javac> task
   will always be valid as long as there's a valid src/ directory
   directly in the project's basedir. Some might argue that I should
   write instead:

   <javac srcdir="${src}" destdir="${classes}" />

   and its the top-level's build file to define these properties, but
   I don't like doing this.

   If as an imported build file, I need to refer to JAR files for custom
   task which are relative to my location, I use ${importdir}/lib/my.jar
   to locate that JAR resource.

4) Use of a URL instead of a file for imports.

   I'm all for it, because it's much more flexible that files;
   nevertheless its problematic... Imagine I bundle up a set of build
   files designed to be imported inside a JAR file. I can do:

   <import href="jar:file:./my.jar!/com/acme/compile.xml" />
   <import href="jar:file:./my.jar!/com/acme/deploy.xml" />

   But then, what if I want to say load a properties file relative
   to compile.xml's location, and assume that like many Ant task
   <property> can only load from files and not URL (this may have
   been fixed in CVS HEAD, but that's beside the point). I can't
   use ${importdir}, because it's not a file, it's a URL in fact.
   Even if I had another magic property called ${importurl}, I still
   can't use it with <property file="???" />, which takes a filename.
   Sure, I could do a <get> to a temporary file, use it, and then
   <delete> it, but that's cumbersome at best!

   `-> Even though using a URL instead of a file for <import> is
       desirable, it raises other issues related to be fact that Ant
       supports URL poorly or only in few places/tasks.

There ;-) I've said quite a bit about <import>. I really look forward
to it, to centralize management of my many build files, without having
to resort to complex XSL solutions that require bootstrapping.

Sorry for the lenght of it. I just hope it's useful.

Have a nice WE all. -DD

> -----Original Message-----
> From: Jose Alberto Fernandez []
> Guys, I think you are missing the point completely
> on this discussion. I do not understand why are you trying
> to impose your coding-style preferences for ANT on other
> people by forcing things like importable and so forth.

I don't think so...

> The issue here is very simple, suppose I have the following
> files:
> /a/b/c/d/e/build.xml:
> <project name="e"><import file="../f/build.xml"/></project>
> /a/b/c/d/f/build.xml:
> <project name="f"><echo>Here is F!</echo></project>
> /p/q/r/build.xml:
> <project name="r"><import file="/a/b/c/d/e/build.xml"/></project>
> /t/u/v/build.xml:
> <project name="v"><import file="/a/b/c/d/e/build.xml"/></project>
> Now, /a/b/c/d directory contains the installation of some 
> useful library of ANT code scripts.
> The two diferent unrelated projects in /p/q/r and /t/u/v are 
> trying to use it. Here the only meaningful way to import "f"
> into "e" is by expanding the file relative "../f/build.xml"
> relative to the location of project "e".

What I've been saying all along! Again, it is the least surprising behavior
for <import> IMHO.

> So I need to be able to write this, in some way. Notice that 
> having or not having basedir defined is just a redhearing.

Sure. But having a basedir define explicitly in a build file that is
being imported will inevitably lead some to think or wonder whether
that basedir will be used or not. I propose it not being used, but if
one also allows that same build file to be also used directly, it will
be used. This dual behavior will again lead to confusion, and is why I
think that at the very least, there should be a runtime warning about
explicit basedir attributes being ignored for all imported files.

> Additionally, projects "e" and "f" may internally need to refer to
> resources (i.e., files) located as part of this library, hence I
> need to have a way to access the local basedir inside this files.

I'm with you again! Which is why I proposed earlier to introduce a
new magic attribute called 'importdir'. This attribute would always
be the directory containing the build file its used into.

To reuse your example, e's 'importdir' would always evaluate to /a/b/c/d/e,
whether it's imported from r or v. Similarly for f, where
its 'importdir' would always be /a/b/c/d/f, even though its imported by r or
v, thru e.

Of course, there currently is no such attribute that takes on a
different values dependending where its used ;-) Implementation-wise,
such an 'importdir' magic attribute would not be replaced as usual
from the project's properties, but during execution of the <import>
task itself, lexicographically in a sense, since the 'importdir' is known
(we're reading the file after all).

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message