On Sun, Jan 6, 2013 at 4:21 PM, Niall Pemberton <niall.pember...@gmail.com> wrote: > 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.
I have attached a patch to MATH-876 which does this - so should resolve all issues https://issues.apache.org/jira/browse/MATH-876 > 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
