On 11/02/2013 11:04 AM, sebb wrote: > On 2 November 2013 08:44, Thomas Neidhart <thomas.neidh...@gmail.com> wrote: >> On 11/02/2013 09:29 AM, Thomas Neidhart wrote: >>> On 11/02/2013 01:17 AM, sebb wrote: >>>> On 2 November 2013 00:07, sebb <seb...@gmail.com> wrote: >>>>> On 1 November 2013 23:36, Thomas Neidhart <thomas.neidh...@gmail.com> >>>>> wrote: >>>>>> Hi, >>>>>> >>>>>> I can remember that a while ago there was the suggestion to include the >>>>>> latest release version + release date for each commons component on the >>>>>> main page. >>>>>> >>>>>> The idea was really appealing to me, and I did an update of the >>>>>> commons-site to include this information. >>>>>> >>>>>> The result can be seen here: >>>>>> >>>>>> http://people.apache.org/~tn/commons/site/ >>>>> >>>>> Looks useful. >>>>> >>>>>> The updated project can be found here: >>>>>> >>>>>> https://github.com/netomi/commons-site >>>>>> >>>>>> What did I do? >>>>>> >>>>>> - create a script conf/parse-latest-release.py that parses the doap >>>>>> file for each component at >>>>>> http://svn.apache.org/repos/asf/commons/proper/ >>>>> >>>>> The DOAP files aren't always accurate; might be worth considering also >>>>> using the files under >>>>> >>>>> https://dist.apache.org/repos/dist/release/commons/ >>>> >>>> Also, it looks like the script assumes that the entries are in reverse >>>> data order. >>>> That is not necessarily the case (e.g. Betwixt, BSF, Codec, Configuration >>>> etc.). >>>> >>>> And some components have multiple concurrent releases (BSF, JEXL) >>>> though that is probably not important here. >>> >>> I remember reading a release-howto that explained that the latest >>> release shall be on top. Afaict, bsf is the only one not applying this >>> rule, but I can update the script. >> >> sorry I misread your comment, there are several where its in a different >> order. What I find also interesting is that there are at least 2 >> different ways how a release is specified in the doap files. >> >> The result being that the releases are not always displayed here: >> >> http://projects.apache.org/indexes/pmc.html#Apache%20Commons >> >> We should correct all the files imho. > > That assumes there is a "correct" layout.! > > Of course it would be possible to decide on a convention for Commons > regardless of any canonical form.
There is one from the root namespace of the doap file: http://usefulinc.com/ns/doap# The valid structure is as follows: Project release Version revision created If the doap file is in this format it is correctly parsed at http://projects.apache.org/indexes/pmc.html#Apache%20Commons otherwise the release information is not present. btw. I did update the script, it now searches for the latest version. Thomas > >> Thomas >> >>> >>> The reason I parse the doap file is that it also contains the >>> release-date, which may not be easily available/parseble from other >>> resources, e.g. pom or release directory. The positive side-effect of >>> this is also that we know see quickly where the doap file is >>> out-of-date, e.g. lang claims that the last release was 3.0. >>> >>> The script is also just a quick way to generate the properties file, but >>> this can be manually edited and committed, as the script is not called >>> during the maven site generation build. >>> >>> Thomas >>> >>>>>> - the script generates a properties file containing the parsed >>>>>> information >>>>>> - use the properties-maven-plugin to load the properties during the >>>>>> maven build >>>>>> - move the index.xml to index.xml.vm to enable velocity filtering >>>>>> and include for each component the respective properties >>>>>> >>>>>> The solution is quite simple, and the properties file can be manually >>>>>> edited if necessary. >>>>>> >>>>>> So WDYT? >>>>>> >>>>>> btw. transaction is still listed as proper component, although already >>>>>> moved to dormant in svn. >>>>>> >>>>>> Thomas >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> 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 >> > > --------------------------------------------------------------------- > 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
