In my humble opinion, DOAP files should be auto-generated and published to public components sites. 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.
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. 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. 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
