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. > 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
