On Wed, Dec 26, 2012 at 6:32 PM, 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.
Yes, but I think it would have been better to leave the commons.component.id property unchanged and add a commons.osgi.symbolicName property to commons math's pom to get what you wanted for the osgi bundle. Niall >>> 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 > 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. > Maybe the best approach is to define commons.project.id and have the > download plugin use that property instead. What do others think? > > 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. > > 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
