You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2004/06/14 02:15:39 UTC
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>
<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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Gump compatible ant tasks and data types
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Gump compatible ant tasks and data types
Posted by Niclas Hedhman <ni...@hedhman.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Gump compatible ant tasks and data types
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Monday 14 June 2004 20:33, Stephen McConnell wrote:
> WDYT?
I think you are in too deep water for me... Maybe someone else swims better.
To me Gump could be copying the dependent Jars into a known temporary
location, and has X number of BASH commands defined to execute, in which the
classloading / other arguments are constructed.
Cheers
Niclas
--
+------//-------------------+
/ http://www.bali.ac /
/ http://niclas.hedhman.org /
+------//-------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Gump compatible ant tasks and data types
Posted by Leo Simons <ls...@jicarilla.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: Gump compatible ant tasks and data types
Posted by Stephen McConnell <mc...@apache.org>.
Niclas Hedhman wrote:
> 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?
Without a mechanism to construct paths resolved via gump (or a gump
environment and set of rules), you have to construct gump descriptors
for each potential classloading scenario. I.e. a gump file for
building, another gump file for generating plugin descriptions, a third
gump file to run tests.
Clearly a manually maintained set of gump files would be impractical
which led to the thinking concerning either (a) automated gump file
generation, or (b) gump integration within ant types and tasks. I'm of
the opinion that integration would be a much better way to go. So - the
question is - how to achieve this?
Taking a non-api approach ...
Gump is creating artifacts along the lines of the following:
[root] == /usr/local/gump/public/workspace
[module] == avalon
[project] == avalon-util-i18n
[output-jar] == target/avalon-util-i18n-[datestamp].jar
If I understand correctly, Gump then copies the file referenced by
[output-jar] to a repository:
[cache]/[module]/jars/avalon-util-i18n-20040613.jar
With the single exception of [module] handling, this the same as the
cache structure used in maven, avalon-repository and the the build tasks
I'm using. In effect it seems to me that we are really close to being
able to provide a model where gump delegates classpath management to a
build container if the the above could be represented as:
[cache]/[group]/jars/avalon-util-i18n-20040613.jar
Keeping in mind that I'm thinking while witting - it seems to me that if
we could construct the [group] based on either a declaration in a gump
file (e.g. a project level group id), or possibly via nested [mudules]
(e.g. /[avalon]/[util] ) - then a build system launched by gump could do
gump artifact resolution and subsequent publication from/to a gump
repository using the following two input parameters
* [cache] directory
* [datestamp]
(and possibly a list of project id to group id mappings where a standard
convention is not used)
WDYT?
Stephen.
--
|---------------------------------------|
| 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
Re: Gump compatible ant tasks and data types
Posted by Niclas Hedhman <ni...@hedhman.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org