| 1 | <html>
|
|---|
| 2 | <head>
|
|---|
| 3 | <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
|
|---|
| 4 | <title>Ant Functional Requirements Document</title>
|
|---|
| 5 | </head>
|
|---|
| 6 | <body>
|
|---|
| 7 | <h2>Ant Functional Requirements</h2>
|
|---|
| 8 | <h3>Roles</h3>
|
|---|
| 9 | <p><b>User: </b>runs Ant with a complete build specification and/or
|
|---|
| 10 | writes Ant build specifications.</p>
|
|---|
| 11 | <p><b>Task Developer: </b>writes/modifies Ant tasks.</p>
|
|---|
| 12 | <p><b>Extensions Developer: </b>develops extensions like a GUI, IDE plugin,
|
|---|
| 13 | (scripting extension?)</p>
|
|---|
| 14 | <p><b>Core Developer: </b>works on the Ant core</p>
|
|---|
| 15 | <h3>Requirements from the Ant User perspective</h3>
|
|---|
| 16 | <p>It should be easy to write a build file for small Java programs. It should
|
|---|
| 17 | be possible to write a build file set for large Java systems. Maintenance
|
|---|
| 18 | of such a set should be easy (e.g. no duplication of information).</p>
|
|---|
| 19 | <p>Every build process contains dependencies (e.g. item A needs B to be available
|
|---|
| 20 | before its own build can start). It should be possible to specify these
|
|---|
| 21 | dependencies in a declarative way.</p>
|
|---|
| 22 | <p>Suppose a working build specification for system A is available. It should
|
|---|
| 23 | be possible for system B to declare dependencies to <i>(modules of?)</i> system
|
|---|
| 24 | A without touching the build specification of A. Ant should be able to handle
|
|---|
| 25 | dependencies between modules which form a DAG.</p>
|
|---|
| 26 | <p>It should be possible to modify details of the actual build (e.g. classpath,
|
|---|
| 27 | used compiler) without the need to change the build specification. This
|
|---|
| 28 | feature is needed when starting Ant (e.g. configuration with command line
|
|---|
| 29 | parameters) and for a subproject build driven by the build of a dependent
|
|---|
| 30 | project.</p>
|
|---|
| 31 | <p>Often similar items have to be built. Therefore it should be possible
|
|---|
| 32 | to provide general <i>(template?)</i> build specifications, and to declare for
|
|---|
| 33 | a concrete item that it should be built according to such a general specification.</p>
|
|---|
| 34 | <p>One result of the build process should be a log which shows what has been done.</p>
|
|---|
| 35 | <h3>Requirements from the task developer perspective</h3>
|
|---|
| 36 | <p>A task should not need to know the structure of a build specification.
|
|---|
| 37 | It would have to provide an interface (not necessarily in the Java language
|
|---|
| 38 | sense) for the Ant core to input the necessary configuration attributes
|
|---|
| 39 | and to execute the task). There should be a standard functionality to allow
|
|---|
| 40 | a task doing log output.</p>
|
|---|
| 41 | <p>An interface (again not necessarily in the Java language sense) should
|
|---|
| 42 | be provided which allows a task to get <i>(and set?)</i> information about it's
|
|---|
| 43 | context in the build process.</p>
|
|---|
| 44 | <h3>Requirements from the extensions developer perspective</h3>
|
|---|
| 45 | <p>The Ant core should be independent from a specific representation of the
|
|---|
| 46 | build specification. It should be possible to create a specification programmatically
|
|---|
| 47 | (thereby allowing the introduction of new representations). The core should
|
|---|
| 48 | do no in- or output itself. Build errors should always lead to throwing
|
|---|
| 49 | an Exception.</p>
|
|---|
| 50 | <p>Access to the current state of a build should be available, and its modification
|
|---|
| 51 | possible.</p>
|
|---|
| 52 | </body>
|
|---|
| 53 | </html>
|
|---|
| 54 |
|
|---|
