forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: [jira] Updated: (FOR-617) Forrest DOAP file
Date Thu, 26 Jan 2006 00:10:28 GMT
Ross Gardler wrote:
> Diwaker Gupta wrote:
> >David Crossley wrote:
> >
> >>The new is now
> >>available. Forrest is not yet listed.
> >>
> >>Do we need to change our DOAP file [1]
> >>or maybe transform into a different syntax?
> >>[1]
> >>
> >>Will it still serve the existing purpose
> >>or do we need to maintain two files?
> >
> >I had created the aforementioned file to facilitate indexing in O'Reilly's 
> >CodeZoo [2]. The current doap.xml is not really a DOAP file -- its 
> >actually an ATOM feed, that contains an embedded DOAP spec as an entry. My 
> >bad in not naming it appropriately.
> I've not looked at the final code for projects.a.o but the original code 
> acepted the DOAP as either a DOAP or an ATOM feed of a DOAP. I hope that 
> this feature has been kept.

I noticed yesterday that David Reid added [1] to
the list of descriptors. Now we show up and our page
has the basic info. So your hope is satisfied.

We should try adding some of the ASF-specific info.


> >So what we need to do is:
> >
> >o create a proper DOAP file for Forrest. There's even a web-based form to 
> >help creating/updating it [3]
> May not be necessary, see above, but also see below.
> There are also a number of RDF additions to the DOAP format in the file 
> requried by projects.a.o. So we need to add those, hopefully they have 
> been documented at projects.a.o (not had time to look yet). If not then 
>  I guess a look over the httpd DOAP will show the full range of 
> additional info since David Reid (who wrote the scripts for this) is an 
> HTTPD dev.
> >o make sure the embedded DOAP in the Atom feed (rename the current 
> >doap.xml to atom.xml?) remains in sync with the actual DOAP.
> If it is necessary then we should add a pipeline to the projectinfo 
> plugin that creates the Atom feed from the DOAP file.
> In fact, it may be a good idea to do it this way anyway, then we are 
> able to provide both formats. Maybe we should ewven think about 
> providing a pattern that strips out all the additional rdf info just in 
> case it messes with external applications (I don't think it wil though).
> Ross

View raw message