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 02:23:35 GMT
(I'm integrating comments to Stefan's mail here as well as I've had a
case of my mail system going horribly wrong while on the road -- a two
hour download of NSCP later and I'm patching things together...)

rubys@us.ibm.com wrote:
> > ant projectfile.xml -props foo=bar;baz=bop [target]
> >
> >  Yes, I'd like to see the props defined this way.. This does reserve
> > the ; and = chars, but I don't see a huge problem with this.
> 
> Semicolons on the command line are real annoying to Unix users...

True since semis usually separate commands. The problem is that I'd
rather not see:

    ant projectfile.xml -prop foo=bar -prop joy=kill [target]

One more thought:

    -prop foo=bar&baz=bap 

Kind of URL-ish like? If not, then I guess that -prop name=value
repeated is the best solution for this.

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

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

Also, I'd think that some sort of global property store that can be
manipulated would be useful for scripting in cases where you can to pass
information between scripts or where you want to have the script set the
buildnumber and buildid.

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

> I don't follow this part.  What is currently defined for nested tasks (in
> this case taskimpl?), then ProjectHelper looks for a createTaskimpl method
> with no arguments that returns an Object.  That object could be anything -
> an instance of a nested class, an existing object, anything. It could even
> be the original object.  Once ProjectHelper has a handle on the object, it
> is configured using reflection.  This process can nest infinitely.

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.

Strawman set of rules:

    Attributes reflected in via bean methods, void return sig
    and String value name.

    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.

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

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

> I realize that this is just an example, but I prefer <script
> language="somelang">...

Yep. Sounds good.

> The jar files that you will want loaded are likely to vary by project.
> Look at the various build.sh/build.bat files around.  What is likely needed
> is for the build.xml to define what jar files are needed by this project.

More strictly, you are saying that a project needs to define what tasks
are needed by the project, yes? This is what taskdef does right now,
but... it's not automagic and I was under the impression that people
wanted this to be automatic. 

One thought of how to provide this is that instead of an ext/ directory,
we have a taskdef/ directory and each task is in that directory by
taskname used in the build file. For example:

   <target name="main">
     <copydir src="foo/" dest="bar/"/>
   </target>

would pick out the taskdef in:

  $install_dir/taskdefs/copydir.jar

This would make it pretty simple for users on a multi user machine to
provide their own tasks by placing them in a $user.dir/ant/taskdefs
directory.

Then, if special tasks needed to be provided with a source base, there
could be a tag in the build.xml file:

    <taskdefs localdir="customtasks/"/>

To address Stefan's comments about locating the ant distribution
directory via ENV_VARs, there isn't a way from Java itself to access
environment variables. I guess in the shell script wrappers we could
have something that really called:

    java -Dant.dir=../`pwd` org.apache.ant.Main $*

> As hardcoding of jar paths inside of the build.xml is likely to cause more
> problems, what would probably be better is for there to be a centralized
> registry of projects.  Perhaps inside of the ant $install_dir someplace
> should be a set of xml files which describe projects.  Each could simply
> contain the path to a single jar file, and optionally the path to the
> build.xml file used to build it.  Any given build could be run in a shallow
> mode (only this project, assume dependencies are up to date), or deep.

Yes, but a centralized registry takes away transparency when it comes to
delivering custom tasks with your project. I don't want to be in a case
where in order to build a project, I have to read instructions that say
"register these jars with these task names in your ant distribution".
Something like the above strawman allows system/user/project taskdefs in
a fairly sane way. What do people think?

> Similar to above, I'd like tasks to be able to be placed wherever it makes
> sense (imagine a word in a few years where many shrink-wrapped products
> deliver their own taskdefs!).  Nor do I believe that all tasks themselves
> need to be open source (I realize how sacrilegious this statement in this
> context ;-) )  All that ant needs is a means to determine how to find the
> jar, and optionally how to build it.

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.

More to the point (and to address Stefan's comment), I guess I was
really trying to solve the case where we have a bunch of tasks in our
source tree and I didn't want to build all of them because I didn't have
required libraries. I wasn't trying to establish any other kind of
precedent.

But thinking about it, I'd like to remove the thought of providing the
sourcecode to optional tasks from the distribution, just set up the
source code tree to ant itself to work in this way. Build the core
first, then when you build any optional tasks, they build their jars
into the taskdefs/ directory for zipping and distribution.

> > In cases where the user must specify an absolute path on a
> > windows machine that starts with a drive letter, it should look like
> > 'C:/foo/bar'
> 
> +1 for an internal canonical representation.
> 
> -0.9944 for requiring users to be aware of it.  You and I write code
> knowing that it will run on multiple platforms, so this would not be a
> problem for us.  Users who only use Windows should not have to use a
> "foreign" format merely because somebody else uses the same tool on another
> platform
> 
> Particularly as Java itself doesn't require this.

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.

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

.duncan


Mime
View raw message