gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Gump compatible ant tasks and data types
Date Mon, 14 Jun 2004 00:15:39 GMT

Hi guys!

Sorry - but this is a longish email.

I'm starting to entertain some thoughts concerning the integration of 
gump into a set of custom ant tasks and data types that I'm using to 
build Avalon.  Initially I was thinking about generating gump 
descriptors - but I'm starting to think that this is the wrong direction 
and that I should really be looking into task and datatype integration.

What I have in place is a small model that defines a project in terms of 
dependencies and plug-ins.  These description are sufficient to create 
six different path constructs required to build respective target project.

These path constructs include:

   1. main java compile classpath
   2. unit test classpath
   3. runtime api classpath
   4. runtime spi classpath
   5. runtime implementation classpath
   6. composite runtime (4+5+6)

This information is constructed from a small project descriptor.  The 
following example shows the avalon activation package which is itself a 
plugin within another package.

     <project basedir="../../runtime/activation/impl">
       <info>
         <group>avalon/activation</group>
         <name>avalon-activation-impl</name>
         <version>2.0.0</version>
       </info>
       <dependencies>
         <include key="avalon-util-lifecycle"/>
         <include key="avalon-util-i18n"/>
         <include key="avalon-util-defaults"/>
         <include key="avalon-repository-spi"/>
         <include key="avalon-composition-spi"/>
         <include key="avalon-composition-impl"
            build="false" test="true" runtime="false"/>
         <include key="avalon-activation-api"/>
         <include key="avalon-test-components"
            build="false" test="true" runtime="false"/>
         <include key="avalon-test-playground"
            build="false" test="true" runtime="false"/>
       </dependencies>
     </project>

In the above example an <include/> element holds a key to another 
project or external resource definition.  For example, 
'avalon-util-lifecycle' is the key to another project that contains 
dependencies on 'avalon-framework-api'.  In turn, the framework api 
definition references the logkit project.  Logkit references a bunch of 
external resources including log4j, servletapi, mailapi and jms.

 From the point of view of gump integration - all of the tasks that are 
used in this build solution use a common project model to establish any 
of the six principal path definitions.  For example, the following java 
source from a typical task implementation demonstrates how an ant path 
is constructed:

   ResourceRef ref = new ResourceRef( getKey() );
   Definition definition = getHome().getDefinition( ref );
   Path classpath = definition.getPath( project, Policy.BUILD );

The Definition.getPath(..) method is basically building an ant path 
based on the xml project descriptor shown above.  It seems to me that it 
would make a lot of sense for implementation of Definition.getPath(..) 
to link into a small Gump API when resolving the path values.

The essence of the getPath( .. ) method is :

   public Path getPath( Project project, int mode )
   {
       Path path = new Path( project );
       ResourceRef[] refs =
          getResourceRefs( mode, ResourceRef.ANY, true );
       for( int i=0; i<refs.length; i++ )
       {
           ResourceRef ref = refs[i];
           Resource resource = getHome().getResource( ref );
           File file = resource.getArtifact( project );
           path.createPathElement().setLocation( file );
       }
       return path;
   }

 From the above - the important lines with respect to Gump integration 
is the the following:

    Resource resource = getHome().getResource( ref );
    File file = resource.getArtifact( project );
    path.createPathElement().setLocation( file );

Currently, the getArtifact(..) operation pulls in resources from a local 
cache (backed by a number of repositories) based on resource identifier 
information include group, resource name and version.  My theory is that 
I should be able to call runtime gump and request the gump artifact for 
a particular group/name combination.

So - the questions is ... is there a nice small gump API I can build 
against that would enable the possibility for a totally integrated solution?

Cheers, Steve.

-- 

|---------------------------------------|
| Magic by Merlin                       |
| Production by Avalon                  |
|                                       |
| http://avalon.apache.org              |
|---------------------------------------|

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message