gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Gump compatible ant tasks and data types
Date Mon, 14 Jun 2004 12:33:37 GMT
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


Mime
View raw message