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.
avalon/activation
avalon-activation-impl
2.0.0
In the above example an 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
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
