On 26 December 2012 18:32, Phil Steitz <phil.ste...@gmail.com> wrote: > On 12/24/12 1:13 PM, Gilles Sadowski wrote: >> On Mon, Dec 24, 2012 at 09:27:57AM -0800, Phil Steitz wrote: >>> On 12/24/12 4:37 AM, Gilles Sadowski wrote: >>>> Hi. >>>> >>>>> [...] >>>>> >>>>> Commons Math can be downloaded from the following page: >>>>> http://commons.apache.org/math/download_math.cgi >>>> I missed that the "mvn commons:download-page" had generated a new >>>> template page: >>>> src/site/xdoc/download_math3.xml >>>> instead of modifying >>>> src/site/xdoc/download_math.xml >>>> >>>> Questions: >>>> 1. Is the creation of a new template page expected? >>>> 2. In the affirmative, is it automatically taken into account by the "site" >>>> generation? I.e. which of the old and new template will eventually be >>>> used to generate the HTML page? >>>> 3. Should the old template be deleted from SVN? >>>> 4. Given that I did not notice the creation of the new template, it was not >>>> included in the tag, and the download page on the site misses the links >>>> to the new release files. How to fix that? >>> I think I understand what is going on and how to "fix" it, but am >>> not 100% sure. >>> >>> I think the root cause of the problem is r1392022 of the [math] pom, >>> where we changed the commons.component.id property to get correct >>> osgi bundles created. This causes the download plugin to generate >>> the second template above. The site plugin does create an html >>> page, so there are two. What I don't get is why only one of them >>> ends up on p.a.o (the "old" one). In any case, the "new" one has >>> the wrong name, so this needs to be fixed. >>> >>> I don't know enough about the download plugin to figure out how to >>> really fix this. Here is a temporary hack that should fix things. >>> >>> 0) Change commons.component.id back to "math" locally in the pom. >>> 1) Change commons.release.version back to "3.1" >>> 2) run commons:download >>> 3) check in the modified template. >>> 4) generate the site locally >>> 5) scp just the download page (download_math.html) to >>> p.a.o/www/commons.apache.org/math >>> >>> It would probably also work to undo the pom changes after step 3) >>> and then do a full site build and deploy. >> Thanks but, hack for hack, I took the more direct route to directly modify >> the HTML page (which is equivalent to your step 5, IIUC). I hope there >> aren't any ill side effects... > > That was actually my first thought ;) >> >> The rest should be really fixed, i.e. keeping the correct component id and >> having the plugin generate/modify the correct file. >> >> Perhaps, we should open a JIRA report in order not to forget. > > Agreed, but I am not sure if it should be against [math], > commons-parent or the download plugin. > > It looks like the download plugin and the osgi plugin both use the > property commons.component.id. The value of this property ends up
I think that is actually commons.componentid > embedded in the template name - download_xxx.html - that the > download plugin generates. This name *must* match download_xxx.cgi > and the link in site.xml for the download pages to work. I guess > one way we can fix this is to rename download_math.cgi (and fix the > links that point to it elsewhere); but that seems wrong to me. Agreed. > Maybe the best approach is to define commons.project.id and have the > download plugin use that property instead. What do others think? Or the plugin could use the new property, if defined, else revert to commons.componentid. Otherwise we'd need to default the new property value in commons-parent. But the name would still need to agree with any links to the download page. Not sure what generates those. > One other question I have is where exactly does download_math.cgi > come from? I don't see it generated locally or in svn anywhere. It is the same (small) file for all components. In the past AFAIK it was just copied from another component and renamed (on people.a.o). == I have seen another approach which does not use separate cgi/html files. If only I could remember which project used it ...! It would obviously be simpler to have just the one generated file. > Phil >> >> >> Regards (and Merry Christmas!), >> Gilles >> >> --------------------------------------------------------------------- >> 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
