axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: xml-axis/proposals/arch/docs modular-build.html index.html
Date Mon, 08 Jul 2002 09:22:01 GMT
glyn        2002/07/08 02:22:01

  Modified:    proposals/arch/docs index.html
  Added:       proposals/arch/docs modular-build.html
  Describe modular build strategy.
  Revision  Changes    Path
  1.2       +2 -0      xml-axis/proposals/arch/docs/index.html
  Index: index.html
  RCS file: /home/cvs/xml-axis/proposals/arch/docs/index.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- index.html	17 Jun 2002 15:12:15 -0000	1.1
  +++ index.html	8 Jul 2002 09:22:01 -0000	1.2
  @@ -11,6 +11,8 @@
   <a href="architecture-guide.html">Architecture Guide</a> - design concepts
and rationale.</li>
  +<a href="modular-build.html">Modular Build</a></li>
  1.1                  xml-axis/proposals/arch/docs/modular-build.html
  Index: modular-build.html
     <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
     <title>Axis Modular Build</title>
  <style type="text/css">
  .example { background:#ccccff }
  .xml { background:#eeeeee }
  body {  font-family: Verdana, Arial, Helvetica, sans-serif; margin-left: 40px}
  h2 {  text-decoration: underline; background-color: #DCE1FF; background-position: left;
margin-left: -30px}
  h3 {  margin-left: -10px}
  h1 {  margin-left: -30px}
  <body text="#000000" bgcolor="#FFFFFF">
  <img SRC="../../../java/docs/axis.jpg" height=96 width=176></h1></center>
  <h1>Modular Build Proposal</h1>
  <br><i>Feedback: <a href=""></a></i>
  <h3><a NAME="Introduction"></a>Introduction</h3>
  Axis began with a strong architectural vision which resulted in the
  flexibility and generality of the current Axis implementation.
  However, over time the Axis implementation has blurred the clean structure
  envisaged by the architecture with the result that Axis is now quite difficult
  to maintain, extend, and understand, especially for newcomers.
  After v1.0 of Axis has shipped, it is hoped to
  rework Axis into separate, properly layered subsystems along the lines of
  the following diagram.
  <p><img SRC="../../../java/docs/subsystems.jpg" vspace=20>
  However, unless something is done to prevent it, any re-architecture will
  eventually succumb to the problem of eventual blurring of structure as
  code fixes are applied and function is added.
  <h3>Modular Build</h3>
  To help preserve a clean structure once it has been achieved, the build of
  the Axis source could be broken into separate sub-builds which build the
  subsystems from the bottom up and which do not allow more basic subsystems
  to refer to higher level subsystems.
  Clearly this could be done by splitting Axis into separately built Apache
  projects, but this seems to be overkill as several of the Axis subsystems
  are useless in isolation.
  A better approach is to define a partial ordering of subsystems with a
  'depends on' relationship to drive the build.
  Each subsystem would be built in turn and subsystems would be built before
  other subsystems which depend on them.
  In addition, the build of each subsystem should only provide access to the
  subsystems in the transitive closure of the 'depends on' relationship
  starting at the subsystem to be built.
  So, for example, suppose the subsystems A, B, C, and D had the following
  'depends on' relationships:
  A depends on B depends on D
  C depends on D
  Then the build orders would any one of:
  D, C, B, A
  D, B, C, A
  D, B, A, C
  and the classpaths for building each of the subsystems would be:
  D: [base]
  C: D, [base]
  B: D, [base]
  A: B, D, [base]
  where [base] indicates the basic classpath common to all the subsystem builds.
  Apart from preserving the subsystem layering, such a strategy would make
  it trivial to extract subsets of Axis function or replace subsystems
  with alternative implementations. There would also be a re-build and
  re-test advantage in that changes to a higher-level subsystem would
  not require lower level subsystems to be re-built and regression tests of
  lower-level subsystems would be guaranteed not to be impacted.

View raw message