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.

FunctionalRequirements.html 3.0 KiB

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