directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From akaras...@apache.org
Subject svn commit: rev 6474 - in incubator/directory/eve/trunk/eve/xdocs: . backend design frontend
Date Wed, 04 Feb 2004 06:11:20 GMT
Author: akarasulu
Date: Tue Feb  3 22:11:20 2004
New Revision: 6474

Added:
   incubator/directory/eve/trunk/eve/xdocs/building.xml
   incubator/directory/eve/trunk/eve/xdocs/components.xml
      - copied unchanged from rev 6463, incubator/directory/eve/trunk/eve/xdocs/design/components.xml
   incubator/directory/eve/trunk/eve/xdocs/deploying.xml
   incubator/directory/eve/trunk/eve/xdocs/repo-layout.xml
Removed:
   incubator/directory/eve/trunk/eve/xdocs/design/components.xml
Modified:
   incubator/directory/eve/trunk/eve/xdocs/backend/navigation.xml
   incubator/directory/eve/trunk/eve/xdocs/design/navigation.xml
   incubator/directory/eve/trunk/eve/xdocs/design/scm.xml
   incubator/directory/eve/trunk/eve/xdocs/frontend/navigation.xml
   incubator/directory/eve/trunk/eve/xdocs/navigation.xml
Log:
moving things around a little

Modified: incubator/directory/eve/trunk/eve/xdocs/backend/navigation.xml
==============================================================================
--- incubator/directory/eve/trunk/eve/xdocs/backend/navigation.xml	(original)
+++ incubator/directory/eve/trunk/eve/xdocs/backend/navigation.xml	Tue Feb  3 22:11:20 2004
@@ -21,7 +21,7 @@
       <item name="Overview" href="../../index.html"/>
       <item name="Community" href="../../community/index.html"/>
       <item name="Latest News" href="../../news.html"/>
-      <item name="Sub-Projects" href="../../subprojects/index.html">
+      <item name="Subprojects" href="../../subprojects/index.html">
         <item name="Eve" href="/index.html">
           <item name="Design" href="/design/index.html"/>
           <item name="Features" href="/features.html"/>
@@ -38,6 +38,7 @@
     </menu>
 
     <menu name="Resources">
+      <item name="IRC" href="../../irc.html"/>
       <item name="Jira" href=
         "http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
       <item name="Wiki" href="http://wiki.apache.org/directory"/>

Added: incubator/directory/eve/trunk/eve/xdocs/building.xml
==============================================================================
--- (empty file)
+++ incubator/directory/eve/trunk/eve/xdocs/building.xml	Tue Feb  3 22:11:20 2004
@@ -0,0 +1,42 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+  <properties>
+    <author email="akarasulu@apache.org">Alex Karasulu</author>
+    <title>Apache Directory Project: Building Eve</title>
+  </properties>
+  
+  <body>
+    <section name="TODO">
+      <ul>
+        <li>
+          Describe Maven based build and use of POM extension with reactor.
+        </li>
+        
+        <li>
+          Describe the organization of projects from the POV of the POM.
+        </li>
+        
+        <li>
+          Discuss use of a component documentation plugin that uses our 
+          layout and some container information to automatically generate 
+          component documentation.
+        </li>
+        
+        <li>
+          Document goals in maven.xml and what they do.
+        </li>
+        
+        <li>
+          Discuss per project document generation and how that integrates with
+          subproject documents.
+        </li>
+      </ul>
+    </section>
+
+    <section name="Building Eve">
+      <p>
+        Coming soon ...
+      </p>
+    </section>
+  </body>
+</document>
\ No newline at end of file

Added: incubator/directory/eve/trunk/eve/xdocs/deploying.xml
==============================================================================
--- (empty file)
+++ incubator/directory/eve/trunk/eve/xdocs/deploying.xml	Tue Feb  3 22:11:20 2004
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+  <properties>
+    <author email="akarasulu@apache.org">Alex Karasulu</author>
+    <title>Apache Directory Project: Building Eve</title>
+  </properties>
+  
+  <body>
+    <section name="TODO">
+      <ul>
+        <li>
+          Figure out what deployment will take but this is way out there.
+        </li>
+        
+        <li>
+          Perhaps there will be some deployment tools we can build to help
+          configure server components as the server is deployed along with
+          an installer.
+        </li>
+      </ul>
+    </section>
+
+    <section name="Deploying Eve">
+      <p>
+        Coming later ...
+      </p>
+    </section>
+      
+  </body>
+</document>

Modified: incubator/directory/eve/trunk/eve/xdocs/design/navigation.xml
==============================================================================
--- incubator/directory/eve/trunk/eve/xdocs/design/navigation.xml	(original)
+++ incubator/directory/eve/trunk/eve/xdocs/design/navigation.xml	Tue Feb  3 22:11:20 2004
@@ -21,11 +21,13 @@
       <item name="Overview" href="../../index.html"/>
       <item name="Community" href="../../community/index.html"/>
       <item name="Latest News" href="../../news.html"/>
-      <item name="Sub-Projects" href="../../subprojects/index.html">
+      <item name="Subprojects" href="../../subprojects/index.html">
         <item name="Eve" href="/index.html">
           <item name="Design" href="/design/index.html">
-            <item name="SCM" href="/design/scm.html"/>
+            <item name="Repository Layout" href="/design/repo-layout.html"/>
             <item name="Components" href="/design/components.html"/>
+            <item name="Building" href="/design/building.html"/>
+            <item name="Deploying" href="/design/deploying.html"/>
           </item>  
           <item name="Features" href="/features.html"/>
           <item name="Backend" href="/backend/index.html"/>
@@ -41,6 +43,7 @@
     </menu>
 
     <menu name="Resources">
+      <item name="IRC" href="../../irc.html"/>
       <item name="Jira" href=
         "http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
       <item name="Wiki" href="http://wiki.apache.org/directory"/>

Modified: incubator/directory/eve/trunk/eve/xdocs/design/scm.xml
==============================================================================
--- incubator/directory/eve/trunk/eve/xdocs/design/scm.xml	(original)
+++ incubator/directory/eve/trunk/eve/xdocs/design/scm.xml	Tue Feb  3 22:11:20 2004
@@ -6,287 +6,5 @@
   </properties>
   
   <body>
-    <section name="Overview">
-      <p>
-        The design for a project has as much to do with how the source code is 
-        organized as it does the structure of the program.  This section 
-        discusses the software configuration management principals used to 
-        organize, maintain and build Eve's code base.
-      </p>
-      <p>
-        After reading this section you should have gained the following:
-      </p>
-      
-      <ul>
-        <li>
-          Know how the repo is organized and why
-        </li>
-          
-        <li>
-          Ability to navigate source and add to it
-        </li>
-        
-        <li>
-          Know how to build and deploy Eve
-        </li>
-      </ul>
-    </section>
-      
-    <section name="Resources">
-      <p>
-        While reading the next section you might want to use the following 
-        resources:
-      </p>
-        
-      <table>
-        <tr><th>Resource</th></tr>
-        <tr>
-          <td><a href="http://cvs.apache.org/viewcvs.cgi/incubator/directory/eve/trunk/eve?root=Apache-SVN">
-          Eve's Subversion Repository</a></td>
-        </tr>
-          
-        <tr><td>
-          <a href="../../../svn.html">
-          Subversion Documentation</a></td>
-        </tr>
-      </table>
-    </section>
-
-    <section name="Organization">
-      <subsection name="Repository Layout">
-        <p>
-          Within the Subversion repository Eve contains several small Maven 
-          projects that are consolidated into groups based on subsystem.  Each 
-          component within Eve has at least two separate Maven
-          projects.  The layout of component and API projects are based on
-          Eve's structure.
-        </p>
-        
-        <p>
-          A logical distinction is made between various subsystems whose 
-          components are separated out in a heirarchy based on function within 
-          the source code repository.  The aspects of each subsystem shall be 
-          discussed in detail within the documentation set for that subsystem.  
-          Developers looking at Eve's source should know that the Subversion 
-          repository is structured to mimic this component containment 
-          heirarchy.  Here's a brief listing of the directory structure we're 
-          referring to:
-        </p>
-        
-        <source>
-./eve               -- top component projects and subsystems
-  ./frontend        -- contains frontend subsystem APIs and service projects
-    ./common        -- contains shared code common to frontend subsystem
-      ./api         -- API common to all projects in frontend
-    ./buffer        -- frontend buffer service projects
-      ./spi         -- frontend buffer service provider interface project
-      ./pojo-impl   -- frontend buffer component POJO implementation project
-      ./merlin-impl -- frontend buffer component Merlin implementation project
-    ./event         -- frontend SEDA event dispatcher service projects
-      ./spi         -- frontend event dispatcher SPI project
-      ./pojo-impl   -- frontend event dispatcher POJO implementation project
-      ./merlin-impl -- frontend event dispatcher Merlin wrapper impl project
-      ...
-  ./backend
-      ...
-        </source>
-        
-        <p>
-          The structure above my nest deeper for other subsystems.  For example 
-          the backend subsystem has within it other sub subsystems.  Each nested
-          subsystem adds an extra level of directory depth.  In turn this 
-          subsystem may have other subsystems and/or component directories that 
-          have an SPI and an implementation project.
-        </p>
-      </subsection>
-      
-      <subsection name="Subsystem Directories and Common APIs">   
-        <p>
-          Eve is composed of components and these components are logically 
-          grouped into subsystems.  For more on Eve's component oriented design
-          aspects take a look <a href="./components.html">here</a>.
-        </p>
-        
-        <p>
-          Subsystems may contain a common directory used to centralize some 
-          classes shared by the subsystem as a common subsystem API of sorts.
-          Centralization of common code helps localize domain specific classes 
-          and interfaces for a subsystem assigned to a specific function.  Take
-          for example the minor schema subsystem which resides under the 
-          backend subsystem.  The schema subsystem contains a common API for 
-          the various interfaces and classes representing schema objects found 
-          within LDAP and X.500.
-        </p>
-        
-        <p>
-          The most benefit we gain from these subsystem common APIs is in the
-          area of project dependency management.  Natural class dependencies
-          will exist within a subsystem.  When dependent classes are distributed
-          across several Maven projects within the subsystem interproject 
-          dependencies are introduced.  By design dependencies between projects
-          will exist to lightly couple the subsystem.  However these class 
-          dependencies should not drive the project dependencies between 
-          services and components.  If class dependencies are allowed to drive
-          project dependencies, you quickly find a web of cyclic project 
-          dependencies creating build problems.
-        </p>
-      </subsection>
-      
-      <subsection name="Service/Component Directories">
-        <p>
-          The COP based approach as we said is discussed in more detail 
-          within the component design documentation.  However we discuss the
-          effects this has on the layout of the subsystem services and the 
-          components that implement them within the software repository.
-        </p>
-        
-        <p>
-          Components have a service interface and one or more implementations.
-          For reasons described within component documentation we separate out 
-          the service interface into its own jar along with other helper classes
-          and interfaces.  Each implementation is also packaged into its own 
-          jar.  Each jar is essentially built by a separate Maven project.  For 
-          each service within a subsystem, a top level directory is named after 
-          the service like the <em>eve/frontend/buffer</em> directory for the

-          buffer service within the frontend subsystem.  The buffer service 
-          creates and pools expensive direct memory buffers for the frontend.  
-          The service interface is kept within an <em>'spi'</em> project 
-          directory and an implementation is defined within a <em>'pojo-impl'
-          </em> directory.  Other implementations of the service may also get 
-          their own directory.  For example the Merlin specific wrappers may be 
-          packaged under another implementation directory like <em>'merlin-impl'
-          </em>.
-        </p>
-        
-        <p>
-          The service directory layout pattern is simple and outlined below:
-        </p>
-        
-        <table>
-          <tr><th>Directory</th><th>Purpose</th><th>Number</th></tr>
-          
-          <tr>
-            <td>
-              *spi
-            </td>
-            <td>
-              contains the SPI jar project
-            </td>
-            <td>
-              In the immortal words of the highlander, "there can only be one!"
-            </td>
-          </tr>
-          
-          <tr>
-            <td>
-              *pojo-impl
-            </td>
-            <td>
-              contains projects for components that implement the service and
-              are plain old java objects: they depend on the SPI project
-            </td>
-            <td>
-              one or more: some services have bootstrap and solidstate versions
-              and may have more than one implementation
-            </td>
-          </tr>
-          
-          <tr>
-            <td>
-              [container]-*-impl
-            </td>
-            <td>
-              contains projects for components that implement the service and
-              are wrappers around the plain old java objects for specific 
-              containers: they depend on the SPI project and the POJO
-              implementations.  Examples are merlin-impl, loom-impl ...
-            </td>
-            <td>
-              one or more: when we start amassing wrappers for various IoC 
-              containers we'll add them here.
-            </td>
-          </tr>
-          
-        </table>
-      </subsection>
-      
-      <subsection name="Why go to such lengths?">
-        <p>
-          One might ask why we have gone to such lengths to separate out our 
-          code in this fashion with projects for each service SPI and projects
-          for each implementation.
-        </p>
-        
-        <ul>
-          <li>
-            Source code configuration is just as important as the code, 
-            sometimes more so - going the distance is worth it.
-          </li>
-          
-          <li>
-            Clean and clear management of project dependencies.
-          </li>
-          
-          <li>
-            Project directory names clearly imply the purpose.  SPI is for
-            service interfaces.  And the implementations can be differentiated
-            with respect to their design (POJO) or the container they're 
-            destined to run in.
-          </li>
-          
-          <li>
-            Conformance to this pattern down the road will make configuration
-            and deployment to various containers easier to maintain and 
-            fuctionality to perform these tasks may be shared.
-          </li>
-          
-          <li>
-            Container Classloader heirachies can hang multiple implementations
-            under an SPI Classloader if the SPI and implementations are kept
-            separate.
-          </li>
-        
-          <li>
-            A separation of concerns: those interested in a specific container 
-            don't care about the wrapper implementation, setup and configuration
-            of the wrapper implementations for other containers.
-          </li>
-          
-          <li>
-            One pleseant side-effect is that it makes people stop and think 
-            about what they are doing in terms of service interfaces and 
-            component implementations.
-          </li>
-          
-          <li>
-            It makes sense to keep a subsystem's nested subsystems and its 
-            services together under one directory.  This way the directory
-            heirarchy models the project and service dependencies within the
-            system.
-          </li>
-
-          <li>
-            It makes sense to keep the implementations of a service interface
-            together under on umbrella directory for the service.
-          </li>
-        </ul>
-      </subsection>
-    </section>
-      
-    <section name="Building Eve">
-      <p>
-        Put something here about how we use maven and talk about reactor and
-        the organization of projects.  Talk about documentation and site
-        content generation.  Talk about the use of a component documentation
-        plugin.
-      </p>
-    </section>
-      
-    <section name="Deploying Eve">
-      <p>
-        Talk about deployment tools and issues pertaining to the container.
-      </p>
-    </section>
-      
   </body>
 </document>

Modified: incubator/directory/eve/trunk/eve/xdocs/frontend/navigation.xml
==============================================================================
--- incubator/directory/eve/trunk/eve/xdocs/frontend/navigation.xml	(original)
+++ incubator/directory/eve/trunk/eve/xdocs/frontend/navigation.xml	Tue Feb  3 22:11:20 2004
@@ -21,7 +21,7 @@
       <item name="Overview" href="../../index.html"/>
       <item name="Community" href="../../community/index.html"/>
       <item name="Latest News" href="../../news.html"/>
-      <item name="Sub-Projects" href="../../subprojects/index.html">
+      <item name="Subprojects" href="../../subprojects/index.html">
         <item name="Eve" href="/index.html">
           <item name="Design" href="/design/index.html"/>
           <item name="Features" href="/features.html"/>
@@ -38,6 +38,7 @@
     </menu>
 
     <menu name="Resources">
+      <item name="IRC" href="../../irc.html"/>
       <item name="Jira" href=
         "http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
       <item name="Wiki" href="http://wiki.apache.org/directory"/>

Modified: incubator/directory/eve/trunk/eve/xdocs/navigation.xml
==============================================================================
--- incubator/directory/eve/trunk/eve/xdocs/navigation.xml	(original)
+++ incubator/directory/eve/trunk/eve/xdocs/navigation.xml	Tue Feb  3 22:11:20 2004
@@ -21,12 +21,15 @@
       <item name="Overview" href="../../index.html"/>
       <item name="Community" href="../../community/index.html"/>
       <item name="Latest News" href="../../news.html"/>
-      <item name="Sub-Projects" href="../../subprojects/index.html">
+      <item name="Subprojects" href="../../subprojects/index.html">
         <item name="Eve" href="/index.html">
-          <item name="Design" href="/design/index.html"/>
           <item name="Features" href="/features.html"/>
-          <item name="Backend" href="/backend/index.html"/>
-          <item name="Frontend" href="/frontend/index.html"/>
+          <item name="Source Layout" href="/source-layout.html"/>
+          <item name="Components" href="/components.html"/>
+          <item name="Building" href="/building.html"/>
+          <item name="Deploying" href="/deploying.html"/>
+          <item name="Backend Subsystem" href="/backend/index.html"/>
+          <item name="Frontend Subsystem" href="/frontend/index.html"/>
         </item>
         <item name="LDAP" href="../ldap/index.html"/>
         <item name="Janus" href="../janus/index.html"/>
@@ -38,6 +41,7 @@
     </menu>
 
     <menu name="Resources">
+      <item name="IRC" href="../../irc.html"/>
       <item name="Jira" href=
         "http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
       <item name="Wiki" href="http://wiki.apache.org/directory"/>

Added: incubator/directory/eve/trunk/eve/xdocs/repo-layout.xml
==============================================================================
--- (empty file)
+++ incubator/directory/eve/trunk/eve/xdocs/repo-layout.xml	Tue Feb  3 22:11:20 2004
@@ -0,0 +1,269 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+  <properties>
+    <author email="akarasulu@apache.org">Alex Karasulu</author>
+    <title>Apache Directory Project: Repository Layout</title>
+  </properties>
+  
+  <body>
+    <section name="Overview">
+      <p>
+        The design for a project has as much to do with how the source code is 
+        organized as it does the structure of the program.  This section 
+        discusses the configuration management techniques used to organize
+        Eve's source code.
+      </p>
+      <p>
+        After reading this section you should have gained the following:
+      </p>
+      
+      <ul>
+        <li>
+          Know how the repo is organized and why
+        </li>
+          
+        <li>
+          Ability to navigate source and add to it
+        </li>
+      </ul>
+      
+      <subsection name="Resources">
+        <p>
+          While reading the next section you might want to use the following 
+          resources:
+        </p>
+          
+        <table>
+          <tr><th>Resource</th></tr>
+          <tr>
+            <td><a href="http://cvs.apache.org/viewcvs.cgi/incubator/directory/eve/trunk/eve?root=Apache-SVN">
+            Eve's Subversion Repository</a></td>
+          </tr>
+            
+          <tr><td>
+            <a href="../../../svn.html">
+            Subversion Documentation</a></td>
+          </tr>
+        </table>
+      </subsection>
+    </section>
+
+    <section name="Repository Layout">
+      <p>
+        Within the Subversion repository Eve contains several small Maven 
+        projects that are consolidated into groups based on subsystem.  Each 
+        component within Eve has at least two separate Maven
+        projects.  The layout of component and API projects are based on
+        Eve's structure.
+      </p>
+      
+      <p>
+        A logical distinction is made between various subsystems whose 
+        components are separated out in a heirarchy based on function within 
+        the source code repository.  The aspects of each subsystem shall be 
+        discussed in detail within the documentation set for that subsystem.  
+        Developers looking at Eve's source should know that the Subversion 
+        repository is structured to mimic this component containment 
+        heirarchy.  Here's a brief listing of the directory structure we're 
+        referring to:
+      </p>
+      
+      <source>
+./eve               -- top component projects and subsystems
+  ./frontend        -- contains frontend subsystem APIs and service projects
+    ./common        -- contains shared code common to frontend subsystem
+      ./api         -- API common to all projects in frontend
+    ./buffer        -- frontend buffer service projects
+      ./spi         -- frontend buffer service provider interface project
+      ./pojo-impl   -- frontend buffer component POJO implementation project
+      ./merlin-impl -- frontend buffer component Merlin implementation project
+    ./event         -- frontend SEDA event dispatcher service projects
+      ./spi         -- frontend event dispatcher SPI project
+      ./pojo-impl   -- frontend event dispatcher POJO implementation project
+      ./merlin-impl -- frontend event dispatcher Merlin wrapper impl project
+      ...
+  ./backend ... 
+      </source>
+      
+      <p>
+        The structure above my nest deeper for other subsystems.  For example 
+        the backend subsystem has within it other sub subsystems.  Each nested
+        subsystem adds an extra level of directory depth.  In turn this 
+        subsystem may have other subsystems and/or component directories that 
+        have an SPI and an implementation project.
+      </p>
+    </section>
+      
+    <section name="Subsystem Directories and Common APIs">   
+      <p>
+        Eve is composed of components and these components are logically 
+        grouped into subsystems.  For more on Eve's component oriented design
+        aspects take a look <a href="./components.html">here</a>.
+      </p>
+      
+      <p>
+        Subsystems may contain a common directory used to centralize some 
+        classes shared by the subsystem as a common subsystem API of sorts.
+        Centralization of common code helps localize domain specific classes 
+        and interfaces for a subsystem assigned to a specific function.  Take
+        for example the minor schema subsystem which resides under the 
+        backend subsystem.  The schema subsystem contains a common API for 
+        the various interfaces and classes representing schema objects found 
+        within LDAP and X.500.
+      </p>
+      
+      <p>
+        The most benefit we gain from these subsystem common APIs is in the
+        area of project dependency management.  Natural class dependencies
+        will exist within a subsystem.  When dependent classes are distributed
+        across several Maven projects within the subsystem interproject 
+        dependencies are introduced.  By design dependencies between projects
+        will exist to lightly couple the subsystem.  However these class 
+        dependencies should not drive the project dependencies between 
+        services and components.  If class dependencies are allowed to drive
+        project dependencies, you quickly find a web of cyclic project 
+        dependencies creating build problems.
+      </p>
+    </section>
+      
+    <section name="Service/Component Directories">
+      <p>
+        The COP based approach as we said is discussed in more detail 
+        within the component design documentation.  However we discuss the
+        effects this has on the layout of the subsystem services and the 
+        components that implement them within the software repository.
+      </p>
+      
+      <p>
+        Components have a service interface and one or more implementations.
+        For reasons described within component documentation we separate out 
+        the service interface into its own jar along with other helper classes
+        and interfaces.  Each implementation is also packaged into its own 
+        jar.  Each jar is essentially built by a separate Maven project.  For 
+        each service within a subsystem, a top level directory is named after 
+        the service like the <em>eve/frontend/buffer</em> directory for the 
+        buffer service within the frontend subsystem.  The buffer service 
+        creates and pools expensive direct memory buffers for the frontend.  
+        The service interface is kept within an <em>'spi'</em> project 
+        directory and an implementation is defined within a <em>'pojo-impl'
+        </em> directory.  Other implementations of the service may also get 
+        their own directory.  For example the Merlin specific wrappers may be 
+        packaged under another implementation directory like <em>'merlin-impl'
+        </em>.
+      </p>
+      
+      <p>
+        The service directory layout pattern is simple and outlined below:
+      </p>
+      
+      <table>
+        <tr><th>Directory</th><th>Purpose</th><th>Number</th></tr>
+        
+        <tr>
+          <td>
+            *spi
+          </td>
+          <td>
+            contains the SPI jar project
+          </td>
+          <td>
+            In the immortal words of the highlander, "there can only be one!"
+          </td>
+        </tr>
+        
+        <tr>
+          <td>
+            *pojo-impl
+          </td>
+          <td>
+            contains projects for components that implement the service and
+            are plain old java objects: they depend on the SPI project
+          </td>
+          <td>
+            one or more: some services have bootstrap and solidstate versions
+            and may have more than one implementation
+          </td>
+        </tr>
+        
+        <tr>
+          <td>
+            [container]-*-impl
+          </td>
+          <td>
+            contains projects for components that implement the service and
+            are wrappers around the plain old java objects for specific 
+            containers: they depend on the SPI project and the POJO
+            implementations.  Examples are merlin-impl, loom-impl ...
+          </td>
+          <td>
+            one or more: when we start amassing wrappers for various IoC 
+            containers we'll add them here.
+          </td>
+        </tr>
+        
+      </table>
+    </section>
+      
+    <section name="Why go to such lengths?">
+      <p>
+        One might ask why we have gone to such lengths to separate out our 
+        code in this fashion with projects for each service SPI and projects
+        for each implementation.
+      </p>
+        
+      <ul>
+        <li>
+          Source code configuration is just as important as the code, 
+          sometimes more so - going the distance is worth it.
+        </li>
+        
+        <li>
+          Clean and clear management of project dependencies.
+        </li>
+        
+        <li>
+          Project directory names clearly imply the purpose.  SPI is for
+          service interfaces.  And the implementations can be differentiated
+          with respect to their design (POJO) or the container they're 
+          destined to run in.
+        </li>
+        
+        <li>
+          Conformance to this pattern down the road will make configuration
+          and deployment to various containers easier to maintain and 
+          fuctionality to perform these tasks may be shared.
+        </li>
+        
+        <li>
+          Container Classloader heirachies can hang multiple implementations
+          under an SPI Classloader if the SPI and implementations are kept
+          separate.
+        </li>
+      
+        <li>
+          A separation of concerns: those interested in a specific container 
+          don't care about the wrapper implementation, setup and configuration
+          of the wrapper implementations for other containers.
+        </li>
+          
+        <li>
+          One pleseant side-effect is that it makes people stop and think 
+          about what they are doing in terms of service interfaces and 
+          component implementations.
+        </li>
+        
+        <li>
+          It makes sense to keep a subsystem's nested subsystems and its 
+          services together under one directory.  This way the directory
+          heirarchy models the project and service dependencies within the
+          system.
+        </li>
+
+        <li>
+          It makes sense to keep the implementations of a service interface
+          together under on umbrella directory for the service.
+        </li>
+      </ul>
+    </section>
+  </body>
+</document>
\ No newline at end of file

Mime
View raw message