#2

[Stephen McConnell <mc...@apache.org>]

I think some explaining is needed, possibly because I've badly phrased 
the #2 options in prior emails.  The purpose of this email is to 
describe what I think needs to be done at the James level to get James 
properly integrated into Gump so that it provides a good feedback loop.

Now keep in mind that I'm not gump expert - but I'm learning.

Gump lets you invoke an ant project (e.g. the build.xml in James) and in 
doing so, you can direct gump to declare some properties in advance.  If 
the James buildfile were to define the jars it was using as properties, 
then gump can override the James build with jar files generated from 
other projects like DNS, commons, avalon, etc.  Getting the most out of 
gump would require some small updates to the James build procedure:

  1. define a properties file that declares the path to
     the released jar files that you use day-to-day (e.g.
     stuff in <james-dir>/lib, etc.

  2. update the James build.xml to read in these properties
     and use these properties when defining things like the
     project.class.path.

     E.g.

     <project default="main" basedir=".">

       <!--
       load the defintion of released jars from
       the james lib directory
       -->

       <property file="${user.home}/project.properties"/>

       <!--
       Define the classpath based on the properties
       -->
       <path id="project.class.path">
         <pathelement location="${junit.jar}"/>
         <pathelement location="${xerces.jar}"/>
         <pathelement location="${xalan.jar}"/>
         <pathelement location="${xml-apis.jar}"/>
         <pathelement location="${dns.jar}"/>
         <pathelement location="${commons-net.jar}"/>
         <pathelement location="${commons-collections.jar}"/>
         <pathelement location="${jakarta-oro.jar}"/>
         <pathelement location="${avalon-framework.jar}"/>
         ...
       </path>

       ...

     </project>

  3. In the Gump descriptor for James, the definition of the
     jar file corresponding to the property value can be declare
     to be the result of a gump build (e.g. the current DNS, ORO,
     Commons xxx, Excalibur xxx, Cornerstone xxx, etc.). We can
     choose to link to either our local library of jars or to
     the gump generated library.  Linking to the gump version
     is what provides the feedback loop - someone (like me) does
     something to excalibur-pool which inadvertently breaks something
     else - I look at gump and find I have broken a dozen excalibur
     builds, James, Cornerstone, Cocoon, etc.  Based on this info
     I fix whatever it is I have done.

  4. The current James build includes dependencies to Phoenix, when
     in fact this can be separated out to a following stage.  Stage
     one should be building James.  Stage two should be building
     the deployment solution (and Phoenix is the released solution).
     I.e. at the gump level we should defining a gump target that
     builds James core.  A second gump target should be defined
     that builds the james-phoenix deployment solution - which
     would naturally be dependent on james core and phoneix.

  5. James users (like me) can then declare dependencies on James
     core (because I don't have a dependency on Phoenix).  When
     someone in James does something to James that breaks something
     that I'm working on - the feedback cycle to me is around 12 hours.
     I.e. everyone is provided with a soft notification solution.

Hope that clarifies what I'm talking about with respect to #2.

Cheers, Steve.

p.s. and yes, I'm happy to put time into getting that in place.

SJM

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>