Comments on JDD's design doc

[Stefan Bodewig <bo...@apache.org>]

Broken up into the sections as they appear there:

Workspace and Modules
=====================

The distinction between the two is not clear to me at all - why would
I need the separation?

For a really modular build modules need to contain submodules. At
times something that may be a workspace in one context is going to be
a module in another context. servletapi is a module of Tomcat4 and a
workspace of its own right for example.

Judging from the example in "Module Namespace" the notify module
relies on the default module. How does it state this dependency? Rely
on the workspace file writer to manage this? Furthermore it directly
uses a target from the other module, how is the workspace
encapsulating the build here?

And finally I'm all against enforcing a specific naming schema. If the
only way to define a module is inside a file named module.ant, how
would I write slightly different module definitions for different
workspaces?

Target and Task concept
=======================

When talking about setting attributes the red part describes what is
already present in Ant 1.2, why is it red? Would anybody want to
remove the handling of non-string attributes?

I disagree with the "TaskInfo Data Reflection" section when it comes
to nested elements. Back in May 2000 the committers (mainly JDD + Sam
+ Arnout) decided to allow for both "void addObjectType(ObjectType)"
and "ObjectType createObjectType()" signatures - this has been
implemented both in Ant 1.1 and 1.2. 

Why would anybody want to change this concept? What has been wrong
with it? I find it very convenient that by looking at the code I can
easily see what is an attribute and what is a nested element. If the
corresponding signatures would be "void setXXX" in both cases this
simplicity would be removed.

As Jose Alberto has noted in another thread, Ant's success is not
because it is using XML or something, the main reasons are the huge
number of prebuilt tasks and that writing tasks is easy - I completely
agree with him.

To make the transition from Ant1 to Ant2 as easy as possible, task
writers shouldn't have to do too much - changing the naming convention
without a good reason is nothing I (as a task writer) would
appreciate.

Module Properties
=================

The title of the section implies properties had module scope while
later on it reads "Module Properties are accessible through the
Workspace Object Model". What is their scope? I think one would at
least need workspace and module scope. Or - translated into Ant1
nomenclature as I don't follow the workspace/module concept - a way to
pass properties to subbuilds (global scope) but not all of them
(module scope).

Having <property name="foo" value="bar" type="baz" /> restricts
properties to classes with a String constructor, right? 

I'd very much prefer a type registry inside <property> with a
<typedef> that parallels <taskdef>. Something like <fileset> from Ant
1.2 would then become

<typedef name="fileset" classname="org.apache.tools.ant.types.FileSet" />

<property name="myfileset">
  <fileset dir="whatever">
    <include name="...." />
  </fileset>
</property>

this would easily integrate the current data types with the property
system - where the current types should be supported out of the box -
and wouldn't require too many changes to current build files.

Each task library could define types in much the same manner as it
defines tasks.

Without a concept like this, Ant2 won't have the ability to build
paths from several components.

File Filters
============

Something similar to current Ant's <patternset>, although I don't see
how one would use them in a build file. The example shows how to
define them, but how would one actually tell a task to use them?

Can't see the benefit of the example over

<property name="alljava">
  <patternset>
    <include name="**/*.java" />
  </patternset>
</property>

Build Events and Listeners
==========================

As this is the only place that mentions FrontEnds: FrontEnds will need
a way to get user interaction back to the build process. A while back
we talked about this in the context of a prompt task.

Concurrent Task Execution
=========================

"Ant allows for parallel tasks of execution to move within the scope
of a Target" means there is an implicit join (or waitOnSpawnedTasks)
at the end of the target. If so (and I think it should be that way)
state this a little bit clearer.

There needs to a way for the user to specify which tasks to spawn. An
attribute "spawn" common to all tasks and evaluated by TaskAction?

Stefan