gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Project(s) dropped
Date Tue, 04 Feb 2003 13:36:19 GMT


Sam Ruby wrote:
> Nicola Ken Barozzi wrote:
> 
>>
>>> Would you mind if I commented out these lines for now?  They are 
>>> obscuring real errors.  
>>
>>
>> Sure, I hoped to get it done sooner but it seems it will take some 
>> more time.
> 
> 
> For now, I decided to take a "middle of the road" approach... I 
> commented out a bulk of the cents as the errors produced seem to be from 
> a common cause.  What's left appears to be a representative sample. Once 
> these are resolved, the rest can be added back in.

Cool, that's really ok.

> - Sam Ruby
> 
> P.S.  there is no reason the names used in the gump project definitions 
> can't be changed to matched the definitions used elsewhere.  Whatever is 
> easiest.

The problem is a bit more complicated for us, actually.

The fact is that we are doing a wrong thing: when running in Centipede, 
we get the jars that match the project names.

So if a project needs ant.jar, in the Centipede-enhanced descriptor one 
writes:

  <depend project="ant" version="1.5"/>

*If* the Gump project was named "ant", all could work, since the version 
tag would be ignored and the jar has the same name of the project.

The fact is, as you know, that

  1 - there can be more than one jar per project
  2 - projects distribute jars with names that not only are
      different from the project name, but are also with different naming
      convensions

What is needed is a system where you ask for a project and a version, 
and you get back a set of jars. We want it to be mirror-aware too.

This means maintaining a metadata repository that contains all these 
infos. I was thinking that Gump could keep such a metadata repository.

I imagine that for every project name there is a directory that contains 
as many files as the releases, named as the release versions themselves.
The system just needs to get that file and scan it for the actual names.
It would not point to a URL, but to a meta-url that defines a mirroring 
scheme. For example:

  apache://ant/ant.jar
  sourceforge://eob/eob.jar
  sourceforge://eob/eob.jar
  http://url/to/jar       ' no mirroring
  ftp://url/to/jar       ' no mirroring

For apache mirroring we just need to modify the closer.cgi script to 
give us a text or xml representation of the mirror locations.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message