ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Duncan Davidson <james.david...@eng.sun.com>
Subject Re: Ant Principles
Date Wed, 19 Apr 2000 08:30:33 GMT

> 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

Yep. that's consistent with what you just had in your previous mail. I
think I can live with that.

> Let's first discuss usage, then mechanics.

Good call.

>    <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.

Interesting. I'd think a something else than "style" conveys it better,
but I can't think of anything shorter than "defaultattributesetting" at
the current time. I see what you are getting at.

XML syntax is preferable. We don't have a CSS parser, nor do I want to
set up a dependency on it.

Yes, this is a good thought... Got to call it something other than style
though... :)

> >    <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)

Ok, but you are overriding them on the command line just like props. And
I'd assume that style elements would want to be ovverriden as well.

> 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.

Yep, that's the right order.

> 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}".

I'm all for that as I can satisfy all the use cases that I can think of
right now with some combination of what you've said and what we've
already established without using this substitution.

But in doing so, you've proposed:

    style -- String defaults
    file  -- rich file type, defined with a string

I'm not sure that the extra typing given this way is worth not just
calling them properties and throwing out the ${...} usage.

> 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.

Ok. We're matching here. It's an inner class whose type is reflected out
from the parameter passed to setInclude. Add setText, make this a
documented formal behavior that all tasks are exposed to and we're set.

> >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.

Most types I think that we can try to intelligently cast to. For example
if setFilename() took a file, then we try to convert the string to a
file. If it takes an int, we try to convert to an it. In all cases, if
the conversion is not successful, it's a runtime error and we bail.

Doing this would let us collapse file and style back to property btw.

> 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;".  

But if we go with the slightly less flexible model, then all methods are
set*** methods.. Cleaner and simpler.

> 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).

Right, but this model puts the onus on creating the object onto the
implementation of the task and doesn't take care of things. I'd rather
see the former than the latter, even if slightly less flexible.

> >   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.

Hmm. addText sounds like it can be called multiple times. Not that this
is a bad thing as each text could be separated by elements. Though I'd
hate to see a task written that depended on the order of elements to
text by keeping track of internal state. Yech. But it's not enough to
try to block it.

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

What I meant is that this isn't generalized as far as it could be,
simplified and codified into law. That's all. I want to see this as
strictly defined as possible so that it is unambiguous.

> >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?

Oh no. However I say this, it doesn't seem to come out right.

Conditional compilation is needed for a whole different purpose and I
wasn't trying to bring it in here... I was trying to state optional
tasks, like a scripting task that depended on BSF and which might not
exist on the user's machine. I don't think that we should use
conditional compilation for optional tasks, they should be separate
builds. Separate projects that are organized in the ant source tree for
people to use optionally.

> >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.

Yes, but that doesn't let me write a x-platform build script that uses
':' as a path separator. We do know that "C:\" is meaningless on a Unix
platform and just error out on a file creation based on it.

.duncan

Mime
View raw message