youys
/
ant
Not watched
1
0
Fork 1
Code
Releases 0 Wiki Activity
Issues 0 Pull Requests 0 Datasets Model Cloudbrain
You can not select more than 25 topics Topics must start with a chinese character,a letter or number, can include dashes ('-') and can be up to 35 characters long.
Tree: 0d890b4559
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from '0d890b4559'
${ noResults }
ant/docs/ant2/FunctionalRequirements.html

55 lines
3.0 kB
Raw Blame History 

  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>