Re: Gump compatible ant tasks and data types
Niclas Hedhman wrote: On Wednesday 16 June 2004 06:43, Leo Simons wrote: A further goal later on will probably be to have the generation of the gump descriptors execute right before every gump run, which will require a crontab change on brutus and or script change. Really? Can't just the 'Gump Descriptor Generation' be another Gump project?? What Gump would need to support in such case is that the descriptors are re-parsed prior to the invocation, not only at the time of determining the dependency order. In Centipede I had the same problem, and we come up with viprom, but it never really took off as an effort. One possibility is that we add to the Gump descriptor extra elements with their namespace to declare the extra features needed, and then have Gump keep the tags. In this way *any* other program can parse merge.xml and use those values with simple xpath. Another possibility is to have Gump switch to using the Maven descriptor, or a namespaced superset of it... -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump compatible ant tasks and data types
I imagine for the gump people the below is as hard to read as it was for me. Spend some time on ICQ with Steve trying to figure out what he's on about. Basically he's whipped up a rather extensive object model (much more so than gump or maven), a superset of gumps object model. This model is parsed by ant tasks and used to build stuff, populate maven-like repositories, etc. I think the only viable option right now is to have this tool (magic) generate a gump descriptor. And because the way this project works implies doing more advanced classpath management than gump can feasibly do, the only viable option is to generate a descriptor which calls ant which calls ant with fork=true, to get back classloader control. Something like project name=foo ant target=gump property project=bar name=bar.jar reference=jar/ property project=bar name=bar.meta path=../target/meta/bar.meta/ /ant depend project=bar/ /project project name=bar ant target=gump depend property=log4j.jar project=log4j/ /ant depend project=bar/ /project with in the antfile... target name=gump antcall target=main fork=true/ /target In other words, the problem comes down to figuring out how to set what properties. A further goal later on will probably be to have the generation of the gump descriptors execute right before every gump run, which will require a crontab change on brutus and or script change. from the peanut gallery, - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump compatible ant tasks and data types
On Wednesday 16 June 2004 06:43, Leo Simons wrote: A further goal later on will probably be to have the generation of the gump descriptors execute right before every gump run, which will require a crontab change on brutus and or script change. Really? Can't just the 'Gump Descriptor Generation' be another Gump project?? What Gump would need to support in such case is that the descriptors are re-parsed prior to the invocation, not only at the time of determining the dependency order. from the peanut gallery, We are all Code Monkeys :-D Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump compatible ant tasks and data types
On Monday 14 June 2004 08:15, Stephen McConnell wrote: 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? Gump is in Python, and I haven't heard of any Java-Gump binding... If so, what more precisely do you expect? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Gump compatible ant tasks and data types
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
groupavalon/activation/group
nameavalon-activation-impl/name
version2.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; irefs.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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
