I'm a rank ant newbie. The following is a combination of 2.0
suggestions, newbie questions, and confusion. I wouldn't dream
of submitting suggestions at my current level of
(mis)understanding, except that the submission deadline's
tomorrow! Even so, I'd split them off into a separate message,
except that perhaps some of what I'm suggesting is already
possible but I just don't know how. So each of these points
should be considered as: "Can I do this now? If so, how? If
not, please consider it a suggestion for 2.0."
1. Can I do set arithmetic on FileSet's? I need to include most
of our project's compiled classes in a single jar, but leave
two or three of them out so that they can be shipped as
discrete .class files. I can think of a couple of "right"
ways to do this:
a. Define FileSet's "all-sources" and "non-jar-sources";
then define "jar-sources" as "the files in all-sources,
except for those in non-jar-sources", ie. set
subtraction.
b. Define FileSet's "jar-sources" and "non-jar-sources";
then define "all-sources" as "the files in jar-sources,
plus the ones in non-jar-sources", ie. set union. This
corresponds to the "make" way of doing things:
JAR_SOURCES = ...
NON_JAR_SOURCES = ...
ALL_SOURCES = $(JAR_SOURCES) $(NON_JAR_SOURCES)
I do NOT want to have to list the non-jar files twice, since
the lists may get out of sync. Of the above approaches, (a)
would be preferable, since (a)'s "all-sources" can be
generated using a vanilla <fileset> element, but (b)'s
"non-jar-sources" would have to be an explicit (long) list.
I imagine this kind of thing being done with nested FileSet's,
something like:
<fileset id="all-sources" dir="src" include="**/*.java"/>
<fileset id="non-jar-sources" dir="src" include="a/Foo.java,b/bar.java"/>
<fileset id="jar-sources">
<add refid="all-sources"/>
<subtract refid="non-jar-sources"\>
</fileset>
Notes:
- The "jar-sources" FileSet tag above doesn't have a "dir"
attribute; "dir" has to stop being mandatory, at least in
this context.
- A FileSet must be able to contain files from more than
one root directory -- in my example, both the referenced
FileSet's had `dir="src"', but this should NOT be a
requirement.
- There should be no limitation on the number of <add> and
<subtract> elements. Just process them all in the order
given.
- I can't think of any use for set intersection; maybe
others can.
- I think this can be done now with an auxiliary file that
lists the non-jar-sources filenames, and judicious use of
includefile= and excludfile=; though I haven't yet tried
it. But that's ugly. It should be possible to express
this in the buildfile itself, without resorting to
auxiliary files.
- PatternSet's don't really help, since:
- They don't name specific files (which is why they
exist, of course)
- You can't "negate" them
2. Documentation complaint: Where can mappers be used, and
where not? I see documentation for how to construct a
<mapper> element, and of the existing mapper types, but the
*only* thing I can find about where to put one is in examples
of a couple of tasks like <apply> and <copy>. There doesn't
seem to be anything rigourous that says: "you can use a
mapper *here*, and if you do, it reads *this* file list and
produces *that* list".
3. Can a mapper be used in the construction of a FileSet? I'd
like to be able to say something like:
<fileset id="sources" .../>
<fileset id="classes" refid="sources">
<mapper type="glob" from="*.java" to="*.class"/>
</fileset>
I'd say this in "make" something like:
CLASSES = $(SOURCES:.java=.class)
4. Let me register a custom mapper, as <taskdef> does for tasks,
so that I don't have to name the mapper's java class at each
reference.
Ok, that's it for the question/suggestions. Now a couple of
"pure" suggestions -- which may still reflect my ignorance.
5. There's an existing suggestion:
> * Target inheritance. ie The ability to include targets from other
> project files overidining them as necessary (so cascading project
> files).
This should be possible for things other than targets, like
FileSet's and properties. For example, the root buildfile could
specify most of the java source files, but a sub-buildfile could
modify the list (by adding and/or subtracting files). Given my
FileSet-arithmetic proposal, one could say something like:
In the root buildfile:
<fileset id="sources" dir="..."/>
in a sub-buildfile:
<fileset id="sub-sources">
<add superclass="yes"/>
<subtract ... />
<add ... />
...
</fileset>
Of course, if a sub-buildfile doesn't specify a given FileSet,
it should just inherit from its "superclass".
(No reason not to implement <subtract superclass="yes"\>;
someone may find a use for it.)
6. The concepts "fileset" and "path" can be unified, I think.
Both contain, in some sense, a list of files/directories that
I want to do something with. The only difference, really, is
in the nature of the "something" -- pass them off to a task
(fileset), or include them in a task's attribute (path). So
why are there two completely different interfaces to building
these very similar sorts of objects?
The unification could be done this way:
- let me build a <fileset> the same way I can now build a
<path>. Ie. as well as its current arguments, make
<fileset> also accept <pathelement path=""/> elements
(it should parse the provided path into a list).
- <pathelement location=""/> would now be redundant, ie.
depracatable if that seems appropriate.
- eliminate <path> entirely, or keep it as a deprecated
synonym for <fileset> (this works since the 2.0 <fileset>
would be a superset of the 1.x <path>).
- have <classpath> also accept the same sorts of arguments
as the new unified <fileset>.
- <classpath refid=""/> would now accept a reference to a
FileSet; it would just concatenate the FileSet's
members, with the right delimiter.
- when it makes sense, let me specify the delimiter to use
for concatenating a FileSet's members; provide a magic
value that says "use the local system's classpath
delimiter".
I'm not even sure what other uses there are for <path>'s (ie.
besides <classpath>). But if there are any, those could be
treated like <classpath>.
7. Another existing suggestion:
> * It should be possible to modify details of the actual build (e.g. classpath,
> used compiler) without the need to change the build specification.
>
> Do build.compiler and build.sysclasspath cover everything or do we
> need to add more stuff like this?
It should be possible to specify -g, -O, -nowarn, etc., at
runtime, ie. ant should have the equivalent of CFLAGS-style
hooks.
I hope at least some of these have value ... thanks for
listening.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
