ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject Re: Ant Principles
Date Wed, 19 Apr 2000 06:01:47 GMT


.duncan wrote:
>> I'd like to explore further the notion of eliminating properties
entirely.
>> I'd like to see more rationale as to why they are necessary.
>
>The number one example that I can't find any other answer for and which
>needs to be supported is a build identifier that can get inserted
>wherever. Such use could be demonstrated with:
>
>    ant foo.xml -prop buildid=beta2 -prop buildnumber=2422
>
>This is a common need in build systems. Witness Moz having the build id
>prominently displayed at the bottom of the window.

Agreed that tasks need access to this type of information, and that it
should be able to be set via the command line.  Alternative that meets
these requirements and is consistent with what I describe below:

   ant -f foo.xml filter.buildid=beta2 filter.buildnumber=2422

>> In HTML today, you can easily change all <h3> text to be blue through
CSS.
>> The approach does not require passing properties around.
>
>No, but in an automated build system, I don't know if editing a css like
>file is appropriate before calling ant. Now, it may be acceptable to not
>do property substitution of text strings in the build.xml file and to
>perform this differently. The current ${propname} is a concept that I'm
>not married to, just the idea of passing in arguments via the command
>line.

Let's first discuss usage, then mechanics.  Actual excerpt from the
xml-cocoon build.xml:

   <property name="debug" value="on"/>
   <property name="optimize" value="on"/>
   <javac srcdir="${build.src}"
          destdir="${build.dest}"
          debug="${debug}"
          optimize="${optimize}"/>

In the actual file, there is 133 lines separating the declaration and usage
of this property.  Now consider:

   <style name="javac.debug" value="on"/>
   <style name="javac.optimize" value="on"/>
   <javac srcdir="${build.src}"
          destdir="${build.dest}"/>

The way to interpret the first line is to think of it as setting the
default value for the debug attribute for all javac tasks in this project.
I picked an XML syntax, but a CSS or other syntax would do.

Advantages of the approach (independent of syntax): the style element is
unambiguous as to its purpose - even out of context.  Furthermore, it is
verifyable at runtime. Finally, it doesn't require a interpretation of the
contents of strings.

>> Also, imagine an addition to ant where you associate names with paths
via
>> <directory> elements at the top of your project file.  Then we require
all
>> tasks to reference paths by name.  I believe that the resulting
build.xml
>> will be easier to understand and maintain.
>
>Hmmm. Let me see if I follow, are you talking about something like (and
>I think filename is more appropriate than dir as we could have files
>being ref'd):
>
>    <project>
>      <filename id="foo" relativepath="src/foo/bar/bap"/>
>      <filename id="bar" relativepath="build/bap"/>
>      <target name="main">
>         <copyfile srcid="foo" destid="bar"/>
>      </target>
>    </project>
>
>Is this what you are talking about?

Yes, and one could override foo on the command line via:

   ant foo=src/foo main

While the above example seems like extra steps, in practice many of the
file paths are declared as string properties today, and others get used
multiple times (output dir of javac => input to jar)

The general idea is to have a set of named things (xml entites with IDs)
which can be overriden in a well defined sequence, builtin defaults being
the weakest, moving up through installation, project, and task, user
(.antrc) and finally to command line.

Whenever possible, these things should be rich objects and not merely
strings.

The think I'd like to see if we can get away from is the need for
"${prop}".

>Yes, but I don't agree that tasks should necessarily be nested as this
>process indicates. Tasks to me should be a sequential list. What I want
>to do is find a way to pass more complicated data into the task than
>just attribs or tasks. Maybe we use the same sort of thing abstracted a
>bit more.

I don't believe that I'm talking about nesting tasks.  An example that is
already supported (from the build.xml for ant):

    <copydir src="${src.dir}" dest="${build.classes}">
      <include name="**/defaultManifest.mf" />
      <include name="**/*.properties" />
    </copydir>

Note that include is not a task.  In this case, it is an inner class.

>Strawman set of rules:
>
>   Attributes reflected in via bean methods, void return sig
>   and String value name.

Agreed, though other value types may be handy.  Imagine a filename class
from the example above.  In general, if the value is of a non-primitive
Object type other than String, then we should look for an object of that
type with an id matching the value.

The current code allows any XML element (and not just projects, targets,
and tasks, see below) to have an ID which could be used for this purpose.

Other primitive data types (boolean, numerics, etc), could also be handled
as a convenience to the taskdef author.

>   Nested objects are reflected in based on object type. So that
>   if there is a nested element named foo, we look for a setFoo,
>   examine the object type expected, instantiate an object of
>   that type and reflect the attribs of that element on it.
>   And yes, this nests.

Slightly different design pattern than what is currently implemented.  What
is done today is a createFoo is looked for with a signature of
"()Ljava.lang.Object;".  The current design pattern is arguably slightly
more flexible in that one need not return a new object, or even an object
at all.  Imagine:

  <javadoc>
     <splitindex/>
  </javadoc>

createSplitindex could simply set a internal boolean and return null (note
that today this won't work, but returning "" would have the same effect -
and I would gladly accept a bug to fix this).

>   All character data contained in the element other than other
>   elements is collected and reflected into the object via a
>   setText(String) method.

At the moment, it is called addText, so as not to be confused with text
attributes.

>It's the second item that is under generalized and it's this last item
>that we don't have standardized at all.

?

>Yes.. Not all taskdefs should be opensource or even part of the dist.
>What I was trying to get at was a definition for providing the source
>code for optional tasks with the ant distribution so that you could
>optionally build tasks if you wanted them. Something like CPAN except
>that some amount of the source code might come with the source distro.

I hope you are not implying that conditional compilation is merely there
for optional tasks?  Parts of cocoon are built into the cocoon jar
depending on whether or not xt, fesi, jndi, projectX, and doclet are
present.  Similar things will be true for jakarta-taglibs.  And for BSF
itself.

>Hmmm. The butthead in me wants to say that Java programmers that don't
>want to recognize that their code is x-platform should go away. But
>sanity agrees with your statement. Yes, we should have a canonical form
>for filenames. But yes, we should accept whatever users throw in and
>make all attempts to do the right thing.

Code is cross platform, build scripts are nearly so (chmod anyone?), but
parameters specifying file paths are most decidedly not.

>We should be clear that any other representation than the canonical form
>is on a "as can do" basis.

-0.75.  Progress, but not quite there.  "C:\" is unambiguous on Windows
platforms.  For this reason, semicolons should be the path separator on
this platform.

- Sam Ruby



Mime
View raw message