5 Replies Latest reply on May 20, 2005 1:09 PM by starksm64

    Requirements - Top level build - structure

      I'll state the requirements through use cases and then we can move
      to something more concrete like defining a schema for each configuration.
      The xml will be pseudo for now.

      The basics of the top level build are to define some information about what we are
      building and the primary components that make up the build.
      It should provide enough information to be able to bootstrap the rest of the build.

      I'm going to ignore versioning for now and deal with that as a separate
      cross cutting concern on a different topic, but there will obviously be
      some overlap.

      Trivial example:

      <project>
       <info id="jbossas"
       description=JBoss Application Server"
       repository="http://repository.jboss.com"
       cvsroot="cvs.forge.jboss.com/cvsroot/jboss"
       </info>
       <component name="naming"/>
       <component name="transaction"/>
       <component name="server"/>
       etc.
      </project>
      


      Standalone example:
      <project>
       <info id="jbosscache"
       description="JBoss Cache"
       repository="http://repository.jboss.com"
       cvsroot="cvs.forge.jboss.com/cvsroot/jboss"
       </info>
       <component name="jbosscache"/>
      </project>
      


      Federated example:
      <project>
       <info id="portal"
       description="JBoss Portal"
       repository="http://repository.jboss.com"
       cvsroot="cvs.forge.jboss.com/cvsroot/portal"
       </info>
       <extends name="jbossas"/>
       <component name="bb"/>
       <component name="wiki"/>
       etc.
      </project>
      



        • 1. Re: Requirements - Top level build - structure

          So a standalone build, just defines itself as the only primary component.

          A federated build allows you to "extend" other top level builds.

          Another example of federation would be to develop two builds together.
          e.g. the cache developers might build a workspace like:

          <project>
           <extends name="jbossas"/>
           <extends name="jbosscache"/>
          </project>
          


          Allowing them to build jbossas and jbosscache from source together.
          This would automatically override jbossas's inclusion of jbosscache as a binary
          inclusion and make it a source project alongside the other jbossas components.

          • 2. Re: Requirements - Top level build - structure

            This brings in other configuration requirements.

            e.g. the jbossportal federation only wants jbossas as binaries, whereas the
            jbosscache federation wants it as source.

            So we need a configuration option that makes this explicit:

            <project>
             <info id="portal"
             description="JBoss Portal"
             repository="http://repository.jboss.com"
             cvsroot="cvs.forge.jboss.com/cvsroot/portal"
             </info>
             <extends name="jbossas" type="binary"/>
             <component name="bb"/>
             <component name="wiki"/>
             etc.
            </project>
            


            There are other requirements where the extension will be of mixed type,
            e.g.
            1) Portal wants to include the license information, docs from jbossas
            2) Portal does not want to run all the unit tests for jbossas when they run
            their unit tests

            Getting more complicated, the custom cache federation will probably only
            want to run tests for components where cache is actually used?

            You could even imagine the cache project wanting to make a workspace
            that "automagically" includes all the components/builds where the cache module is imported. Which would be good for cutting down the regression testing overhead
            but would be bad for people "fixing" tests rather than fixing the problem.

            • 3. Re: Requirements - Top level build - structure

              What about defining the release structure - a responsibility previously held by the toplevel build. Is this no longer the case?

              • 4. Re: Requirements - Top level build - structure

                I haven't got to the "release" part yet.

                • 5. Re: Requirements - Top level build - structure
                  starksm64

                  So there needs to be a clear mapping of the names used in the references such as extends, component to both the binary and source repositories. There also needs to be a definition of the structure for a component source and binary tree.

                  In terms of a project wanting to import the docs/licenses/* or another component, this is just an alternate artifact reference to the binary repository as I see it. The docs would also seem to be more of a release level reference. The licenses I would expect to be a general feature of a common thirdparty target that pulled the binaries from the repository.