You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Eric Siegerman <er...@telepres.com> on 2001/03/21 01:03:17 UTC
2.0 suggestions / questions
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. erics@telepres.com
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
Re: 2.0 suggestions / questions
Posted by Peter Donald <do...@apache.org>.
At 08:49 20/3/01 -0500, Eric Siegerman wrote:
>On Wed, Mar 21, 2001 at 12:02:38PM +1100, Peter Donald wrote:
>> At 07:03 20/3/01 -0500, Eric Siegerman wrote:
>> >1. Can I do set arithmetic on FileSet's?
>>
>> No need to in most cases.
>> [suggested alternative deleted]
>> Not all tasks support [the alternative] but most that I have needed do.
>
>That's precisely the point of fileset arithmetic -- to factor
>this out in the ant code so that task classes don't need to
>*think* about it.
Yes we do intend to provide base utilities that are accessible to all
classes. In most cases the task writer don't have to think (or will not in
the future).
>Consider this a gripe about the lack of orthogonality in task
>implementations -- and a suggested (partial?) fix. (Dunno
>whether it's a complete fix because I'm too new at ant to know
>how unorthogonal the tasks are in the first place. But at worst,
>this would be a complete fix for one class of irregularities...)
This sort of talk is similar to what has just been discussed recently on
ant-dev. Being able to have aspects handled outside the task and then
"applied to task". Some possible implementations have been a lisp-like (map
function fileitems) or inheritance from base class etc.
>
>> Multiple
>> filesets combined with exclude/include (or patternsets) will work the magic
>> you need.
>
>That's the other point :-) -- to let me factor such similarities
>out in my buildfile, so my task calls don't need to think about
>it.
Not sure what you mean. The filesets already handled nested patterns and
petternsets etc. The task writers don't have to handle it. The places where
tasks do handle it is for backwards compatability.
>> >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>
>>
>> there has been a proposal for this. It may or may not get through - not
>> sure at this moment.
>
>Want to add mapper support to all existing tasks in one go -- and
>to all future tasks where they make sense with *zero* further
>effort? This'll do it: don't bother adding mapper support to
>tasks; instead factor it out so that tasks don't need to worry
>about mappers.
agreed. But as I said - we will have to wait till the vote to see if it
gets through ;) So far no one besides you and me have been positive about
such a feature. (And I am not sure I am completely positive about it). The
problem comes because it adds complexity to the build file - where one of
our main aims is simplicity ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: 2.0 suggestions / questions
Posted by Eric Siegerman <er...@telepres.com>.
On Wed, Mar 21, 2001 at 12:04:13PM +1100, Peter Donald wrote:
> BTW we will be discussing these things on ant-dev rather than ant-user if
> you are interested in participating ;)
Ok, I'm moving this to ant-dev ... crossposting for the benefit of
people in ant-user, in flagrant disobedience of the guidelines :-)
So:
ant-user folks:
please reply to ant-dev, NOT ant-user! I put in a
Reply-To:, but I think the list software will stomp it :-(
ant-dev folks:
I won't make this post longer by pulling back in the
snipped bits; you can find the first part of this thread
in the ant-user archives, under the same subject:
"2.0 suggestions / questions".
On Wed, Mar 21, 2001 at 12:02:38PM +1100, Peter Donald wrote:
> At 07:03 20/3/01 -0500, Eric Siegerman wrote:
> >1. Can I do set arithmetic on FileSet's?
>
> No need to in most cases.
> [suggested alternative deleted]
> Not all tasks support [the alternative] but most that I have needed do.
That's precisely the point of fileset arithmetic -- to factor
this out in the ant code so that task classes don't need to
*think* about it.
Consider this a gripe about the lack of orthogonality in task
implementations -- and a suggested (partial?) fix. (Dunno
whether it's a complete fix because I'm too new at ant to know
how unorthogonal the tasks are in the first place. But at worst,
this would be a complete fix for one class of irregularities...)
> Multiple
> filesets combined with exclude/include (or patternsets) will work the magic
> you need.
That's the other point :-) -- to let me factor such similarities
out in my buildfile, so my task calls don't need to think about
it.
> However I will add set arithmatic to requested features.
Thanks.
> apply/copy are currently the only tasks that use [mappers] ;)
See below...
>
> >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>
>
> there has been a proposal for this. It may or may not get through - not
> sure at this moment.
Want to add mapper support to all existing tasks in one go -- and
to all future tasks where they make sense with *zero* further
effort? This'll do it: don't bother adding mapper support to
tasks; instead factor it out so that tasks don't need to worry
about mappers.
> >I hope at least some of these have value ... thanks for
> >listening.
>
> most of it was good ! ;)
Cool; I'm glad I'm not completely out to lunch. Thanks.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. erics@telepres.com
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
Re: 2.0 suggestions / questions
Posted by Eric Siegerman <er...@telepres.com>.
On Wed, Mar 21, 2001 at 12:04:13PM +1100, Peter Donald wrote:
> BTW we will be discussing these things on ant-dev rather than ant-user if
> you are interested in participating ;)
Ok, I'm moving this to ant-dev ... crossposting for the benefit of
people in ant-user, in flagrant disobedience of the guidelines :-)
So:
ant-user folks:
please reply to ant-dev, NOT ant-user! I put in a
Reply-To:, but I think the list software will stomp it :-(
ant-dev folks:
I won't make this post longer by pulling back in the
snipped bits; you can find the first part of this thread
in the ant-user archives, under the same subject:
"2.0 suggestions / questions".
On Wed, Mar 21, 2001 at 12:02:38PM +1100, Peter Donald wrote:
> At 07:03 20/3/01 -0500, Eric Siegerman wrote:
> >1. Can I do set arithmetic on FileSet's?
>
> No need to in most cases.
> [suggested alternative deleted]
> Not all tasks support [the alternative] but most that I have needed do.
That's precisely the point of fileset arithmetic -- to factor
this out in the ant code so that task classes don't need to
*think* about it.
Consider this a gripe about the lack of orthogonality in task
implementations -- and a suggested (partial?) fix. (Dunno
whether it's a complete fix because I'm too new at ant to know
how unorthogonal the tasks are in the first place. But at worst,
this would be a complete fix for one class of irregularities...)
> Multiple
> filesets combined with exclude/include (or patternsets) will work the magic
> you need.
That's the other point :-) -- to let me factor such similarities
out in my buildfile, so my task calls don't need to think about
it.
> However I will add set arithmatic to requested features.
Thanks.
> apply/copy are currently the only tasks that use [mappers] ;)
See below...
>
> >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>
>
> there has been a proposal for this. It may or may not get through - not
> sure at this moment.
Want to add mapper support to all existing tasks in one go -- and
to all future tasks where they make sense with *zero* further
effort? This'll do it: don't bother adding mapper support to
tasks; instead factor it out so that tasks don't need to worry
about mappers.
> >I hope at least some of these have value ... thanks for
> >listening.
>
> most of it was good ! ;)
Cool; I'm glad I'm not completely out to lunch. Thanks.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. erics@telepres.com
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
Re: 2.0 suggestions / questions
Posted by Peter Donald <do...@apache.org>.
BTW we will be discussing these things on ant-dev rather than ant-user if
you are interested in participating ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
Re: 2.0 suggestions / questions
Posted by Peter Donald <do...@apache.org>.
At 07:03 20/3/01 -0500, Eric Siegerman wrote:
>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!
deadlines are for paid work - we scratch what itches ;) Though we are goin
to move onto the next phase soon - however we will always accept ideas etc ;)
>1. Can I do set arithmetic on FileSet's? I need to include most
No need to in most cases. From one of my build files...
<javac srcdir="${java.dir}"
destdir="${build.classes}"
debug="${debug}"
optimize="${optimize}"
deprecation="${deprecation}">
<classpath refid="project.class.path" />
<src path="${build.src}"/>
<exclude name="${constants.file}" />
</javac>
will include everything in java.dir except ${constants.file} and everything
in build.src.
Not all tasks support this but most that I have needed do. Multiple
filesets combined with exclude/include (or patternsets) will work the magic
you need.
However I will add set arithmatic to requested features.
>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".
apply/copy are currently the only tasks that use it ;) But patches for docs
are accepted ;)
>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>
there has been a proposal for this. It may or may not get through - not
sure at this moment.
>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.
Already requested with line
* provide support for non-hardwired (ie loadable) low-level
components (mappers/itemset-filters/converters). Allow them to be
loaded in either global or a new classloader.
>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.
inheritance of filesets/properties between projects is already there. (Thou
not explicitly stated which I may do).
However inheritance between datatypes is an interesting idea that I will add.
>6. The concepts "fileset" and "path" can be unified, I think.
Already covered under the notion of standardising attributes/developing
more fully fledged notion of includes/excludes/file-patternsets. Will make
it explicit though..
> 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.
yep - definetly ;)
>I hope at least some of these have value ... thanks for
>listening.
most of it was good ! ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*