www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Common XML Project descriptor ( Re: Subtle barriers to entry )
Date Wed, 06 Nov 2002 02:06:43 GMT


Peter Donald wrote:
> On Wed, 6 Nov 2002 11:58, Daniel Rall wrote:
> 
>>Nicola Ken Barozzi <nicolaken@apache.org> writes:
>>
>>>Peter Donald wrote:
>>>
>>>>Secondly make it so each project can have multiple vcs entrys (ie
>>>>Avalon and it's 6 or 7, turbine with the same).
>>>
>>>Hmmm... this descriptor should have a 1-1 relationship with a single
>>>VCS entry, as it defines what in CVS is a "module", as in the Gump
>>>descriptor.
>>
>>Then it's not really a project descriptor, now is it?  We already have
>>plenty of projects at the ASF which have multiple CVS repositories --
>>look at httpd.  Even the new infrastructure project will have several
>>(so it's a growing trend).
> 
> 
> We also have projects that propose one VCS (commons@apache) where codebases 
> have subdirectorys (like serf/, httpunit/ etc). Other projects share mailing 
> list for multiple codebases. Which sort to starts to get back to that icky 
> state of flux that the alexandria (then gump) descriptors went through. 

The truth is that I think you are rught, we will never come to a solid 
relationship with these entities, and history is here to warn us.

> What happens when a particular "resource" is used across multiple codebases? 
> Possible resources being;
> 
> * mailing lists
> * VCS
> * issue trackers
> * developers
> * schedulers/task trackers
> 
> If it was a normalized database model it would be simple because there would 
> just be relationships between the entities. But because XML is a hierarchial 
> data store then it no work.

As you know, Gump resolves this by defining common entities separately 
and "linking" them, like CVS repository info, that can be defined in one 
place and "linked" in all project descriptors.

> Maybe it would be a good idea to start from a fully normalized database model 
> and then work towards exporters that denormalize for particular purposes. The 
> information could then be shared between different users and they could 
> formulate it as they desire.

Conceptually it's basically the same as with what Gump does, but I'm 
interested in pursuing alternative paths if they are better.

What do you see in the Gump-like information-sharing system that needs 
to be redone or that cannot be done?

> Does this sound like a good idea? 

Sure clears up the picture :-)

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


Mime
View raw message