> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
>
> 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.
>
I agree that ${basedir} should be the value of basedir for the main
buildfile being executed. But what I think is necessary is to have
access to the basedirs of the imported file in a systematic, deterministic
and conflict free way. I do not think we need some special "importdir"
what we need is ${basedir.importedprojectname} and so on. This properties will
point to the where the local basedir for that local file is suppose to be.
Now things are not that simple. There is an issue with names and name clashing.
If I have an imported project named "F", it stands to reason that the file
may contain references to ${basedir.F} when some local resource is being
accessed.
So, one cannot just change the name of the project in the import statement
<import file="xyz.xml" name="R"/> in order to resolve a conflict,
unless the process translates the ocurrences of ${basedir.F} to ${basedir.R}.
And any other such variable.
It seem to me that we need some diferent variable syntax to refer to this local
definitions which are expanded during the parsing of the file. Something like:
$~{basedir} or [EMAIL PROTECTED]
which gets rewritten to some unique property name to use inside the file.
>
> 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.
>
I suggest having an attribute for import: localfile="xyz". Which will
be resolved with respect to the local ${basedir} and not the global.
This is equivalent to do: file="[EMAIL PROTECTED]/xyz" but it is easier to
write.
>
>
> >
> > 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.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
