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
necessary.
`-> 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
basedir.
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 [mailto:[EMAIL PROTECTED]
>
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
