On 12 March 2013 07:26, Simone Tripodi <simonetrip...@apache.org> wrote: > In my humble opinion, DOAP files should be auto-generated and > published to public components sites.
Provided that it is possible to control the contents adequately, that seems sensible. > What's the reason to distribute it in the source archive, when > releasing? DOAPs are intended to be consumed by crawlers/robots/... > and doesn't affect the build at all. Indeed, that is my point. > In Apache Onami we are using the Maven DOAP Plugin[1] to built it and > attach it to the site generation, it rebuilds every time the releases > history, and populates metadata just grabbing them from the POM, > avoiding manual maintenance of same metadata in two different places. But Onami does not appear in projects.apache.org! I could not find the Onami DOAP - where is it? > Indeed, in components I've touched, I have always had to fill missing > data of years of releases, and we often overlooked, while voting a > release, that wrong DOAPs have been included in archives - have a look > at the 1.2.2 tag of fileupload[1] where 1.2, 1.2.1 and 1.2.2 itself > are missing. Which suggests that having the doap in trunk does not actually help with ensuring it is updated. It would be easier to fix up the manually created doaps if they were all in one directory. > my 2 cents, > -Simo > > [1] http://maven.apache.org/plugins/maven-doap-plugin/ > [2] > http://svn.apache.org/repos/asf/commons/proper/fileupload/tags/commons-fileupload-1.2.2/doap_fileupload.rdf > > http://people.apache.org/~simonetripodi/ > http://simonetripodi.livejournal.com/ > http://twitter.com/simonetripodi > http://www.99soft.org/ > > > On Tue, Mar 12, 2013 at 12:30 AM, sebb <seb...@gmail.com> wrote: >> The DOAP files are currently held under >> >> /commons/proper/<component>/trunk/doap_<component>.rdf >> >> This is sort of convenient for editting, but means the doap file gets >> included in tags and branches and may get included in source. >> If included in source, the release date may be missing or inaccurate. >> >> The DOAP files are only needed for building projects.apache.org, so >> don't really belong as part of the source. >> >> So I think the files should be moved out of trunk. >> >> They could be moved into the parent directory, i.e. >> >> /commons/proper/<component>/doap_<component>.rdf >> >> The advantage is that it is still part of the component SVN tree; the >> disadvantage is that it is slightly awkward to update, as one must >> checkout the folder using --depth filesonly. >> >> Another possibility would be to create a separate directory for all >> the DOAP files. >> This would create a bigger workspace, but would be slightly easier to >> use - omitting the --depth qualifier would not result in a huge >> accidental checkout of all tags and branches. >> >> [Whatever directory is chosen, it would be trivial to update the >> projects.a.o build config file.] >> >> Thoughts? >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
