Re: FOP Release Automation
in released versions until v1.1, whole website was included in src/documentation, using the old Forrest schema. So, until v1.1, the website repo may embed directly versionned doc. I don't think we need to remove them, just adding or removing a link in sidenav will be sufficient (0.95 doc is always on website). Beginning with fop-next, ie current trunk, we could move trunk doc into fop trunk repos and apply svn:externals in website repo. Attached, I've listed links to versionned doc in CMS FOP -- I like grepwin ;-). Note that for links to latest version, we used variables at the top of MDtext, for easier update during release process. I see no need to redirect anything, just change some values in 5 files. 2014-05-28 6:33 GMT+02:00 Clay Leeds : > Hi, > > I thought I'd give an update on my research of speeding the RELEASE process... > > I've spent some time researching, and I've asked for some assistance from > site-dev@... > > Among the ideas I've been researching are: > - MarkDown PreProcessor[1] > - svn hook > > I'm not married to either of these solutions, but they look interesting. > > Of course, another idea, is to do it the OLD way, and I'd be happy to go > through and update the MarkDown files with the latest/updated version. > > MarkDown PreProcessor (a sample I thought was interesting) > [1] > http://aaronparecki.com/articles/2012/09/01/1/some-enhancements-to-markdown > > More inline... > > On May 23, 2014, at 1:00 AM, Pascal Sancho wrote: >> Hi, >> >> The FOP package should not embed the whole website, but only the >> documentation part, more precisely only the relevant version folder. >> >> Currently, FOP doc folder is referenced as svn:externals in FOP repo, >> resulting on extra irrelevant info, such as other versions, >> miscellaneous processes, general info, etc. >> >> IMHO, FOP versionned doc should be in FOP repo, and Website repo >> should refer to each FOP versionned doc through svn:externals prop. >> >> WDYT? > > +1 Pascal... Makes sense to me. There's a lot of cruft in there... > > We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or > adjust the site a bit to move the OLD versions somewhere 'out of the way'... > (And then add 301 redirects... ;-) -- pascal fop\dev\design\parsing.mdtext ../../trunk/embedding.html ../../trunk/extensions.html fop\dev\extensions.mdtext ../trunk/extensions.html fop\dev\faq.mdtext ../trunk/compiling.html fop\dev\svg.mdtext ../trunk/graphics.html fop\dev\tools.mdtext ../trunk/compiling.html fop\faq.mdtext [currentFop_config_general]: 1.1/configuration.html#general-elements [currentFop_embedding_configExt]: 1.1/embedding.html#config-external [currentFop_embedding_configInt]: 1.1/embedding.html#config-internal [currentFop_embedding_multithreading]: 1.1/embedding.html#multithreading [currentFop_fonts]:1.1/fonts.html [currentFop_graphics]: 1.1/graphics.html [currentFop_graphics_batik]: 1.1/graphics.html#batik [currentFop_graphics_resol]: 1.1/graphics.html#resolution [currentFop_graphics_svgPdfText]: 1.1/graphics.html#svg-pdf-text [currentFop_graphics_svgScaling]: 1.1/graphics.html#svg-scaling [currentFop_hyphenation_support]: 1.1/hyphenation.html#support [currentFop_metadata]: 1.1/metadata.html [currentFop_output_generalFonts]: 1.1/output.html#general-fonts [currentFop_output_pdfFonts]: 1.1/output.html#pdf-fonts [currentFop_output_pdfPostProcess]:1.1/output.html#pdf-postprocess [currentFop_output_pdfWatermark]: 1.1/output.html#pdf-watermark [currentFop_pdfencryption]:1.1/pdfencryption.html [currentFop_running_memory]: 1.1/running.html#memory [currentFop_servlets]: 1.1/servlets.html#servlet [currentFop_servlets_engine]: 1.1/servlets.html#servlet-engine [currentFop_servlets_ie]: 1.1/servlets.html#ie [currentFop_servlets_xslt]:1.1/servlets.html#xslt fop\fo.mdtext [fopLatest_config]: 1.1/configuration.html fop\index.mdtext [fopLatest]: 1.1/ [fopLatest_ouput]: 1.1/output.html fop\maillist.mdtext [fopLatest-runningXalan]: 1.1/running.html#check-input fop\quickstartguide.mdtext [currentFop_compile]: 1.1/compiling.html [currentFop_config]: 1.1/configuration.html [currentFop_running]: 1.1/running.html [currentFop_embedding]: 1.1/embedding.html [currentFop_servlets]: 1.1/servlets.html [currentFop_anttask]: 1.1/anttask.html [currentFop_index]: 1.1/index.html
RE: FOP Release Automation
Hi Clay and Pascal, Sorry for my late reply with this. Pascal your idea makes a lot of sense as that will keep all versioned docs with their associated FOP version. I haven't had much of a chance to look at this over the last couple of days but am planning on spending some time in the coming days. Clay, both of what you mention sound intriguing so I'll take a look at those. I think updating it manually will be a last resort as even just writing an ant script would be preferable! If it does come to a script, the idea of copying the trunk folder and doing a find / replace on say "trunk" and replacing with "2.0" would be an option (with some caveats), but I'll investigate the other methods first. I'll keep you posted. Regards, Robert Meyer > Subject: Re: FOP Release Automation > From: the.webmaes...@gmail.com > Date: Tue, 27 May 2014 21:33:32 -0700 > To: fop-dev@xmlgraphics.apache.org > > Hi, > > I thought I'd give an update on my research of speeding the RELEASE process... > > I've spent some time researching, and I've asked for some assistance from > site-dev@... > > Among the ideas I've been researching are: > - MarkDown PreProcessor[1] > - svn hook > > I'm not married to either of these solutions, but they look interesting. > > Of course, another idea, is to do it the OLD way, and I'd be happy to go > through and update the MarkDown files with the latest/updated version. > > MarkDown PreProcessor (a sample I thought was interesting) > [1] > http://aaronparecki.com/articles/2012/09/01/1/some-enhancements-to-markdown > > More inline... > > On May 23, 2014, at 1:00 AM, Pascal Sancho wrote: > > Hi, > > > > The FOP package should not embed the whole website, but only the > > documentation part, more precisely only the relevant version folder. > > > > Currently, FOP doc folder is referenced as svn:externals in FOP repo, > > resulting on extra irrelevant info, such as other versions, > > miscellaneous processes, general info, etc. > > > > IMHO, FOP versionned doc should be in FOP repo, and Website repo > > should refer to each FOP versionned doc through svn:externals prop. > > > > WDYT? > > +1 Pascal... Makes sense to me. There's a lot of cruft in there... > > We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or > adjust the site a bit to move the OLD versions somewhere 'out of the way'... > (And then add 301 redirects... ;-) > > Cheers! > > Clay Leeds @ the.webmaes...@gmail.com > "My religion is simple. My religion is kindness." > HH the Dalai Lama of Tibet >
Re: FOP Release Automation
Hi, I didn't remember that I've rewritten the release page [1] (only refactor, no content change except website update). So, reading it back can figure how simple such task should be. Comments? [1] http://xmlgraphics.apache.org/fop/dev/release.html#cms 2014-05-28 10:57 GMT+02:00 Robert Meyer : > Hi Clay and Pascal, > > Sorry for my late reply with this. > > Pascal your idea makes a lot of sense as that will keep all versioned docs > with their associated FOP version. I haven't had much of a chance to look at > this over the last couple of days but am planning on spending some time in > the coming days. > > Clay, both of what you mention sound intriguing so I'll take a look at > those. I think updating it manually will be a last resort as even just > writing an ant script would be preferable! If it does come to a script, the > idea of copying the trunk folder and doing a find / replace on say "trunk" > and replacing with "2.0" would be an option (with some caveats), but I'll > investigate the other methods first. > > I'll keep you posted. > > Regards, > > Robert Meyer > >> Subject: Re: FOP Release Automation >> From: the.webmaes...@gmail.com >> Date: Tue, 27 May 2014 21:33:32 -0700 >> To: fop-dev@xmlgraphics.apache.org > >> >> Hi, >> >> I thought I'd give an update on my research of speeding the RELEASE >> process... >> >> I've spent some time researching, and I've asked for some assistance from >> site-dev@... >> >> Among the ideas I've been researching are: >> - MarkDown PreProcessor[1] >> - svn hook >> >> I'm not married to either of these solutions, but they look interesting. >> >> Of course, another idea, is to do it the OLD way, and I'd be happy to go >> through and update the MarkDown files with the latest/updated version. >> >> MarkDown PreProcessor (a sample I thought was interesting) >> [1] >> http://aaronparecki.com/articles/2012/09/01/1/some-enhancements-to-markdown >> >> More inline... >> >> On May 23, 2014, at 1:00 AM, Pascal Sancho wrote: >> > Hi, >> > >> > The FOP package should not embed the whole website, but only the >> > documentation part, more precisely only the relevant version folder. >> > >> > Currently, FOP doc folder is referenced as svn:externals in FOP repo, >> > resulting on extra irrelevant info, such as other versions, >> > miscellaneous processes, general info, etc. >> > >> > IMHO, FOP versionned doc should be in FOP repo, and Website repo >> > should refer to each FOP versionned doc through svn:externals prop. >> > >> > WDYT? >> >> +1 Pascal... Makes sense to me. There's a lot of cruft in there... >> >> We'd have to either `svn:externals` a bunch of single files (svn-1.7+), or >> adjust the site a bit to move the OLD versions somewhere 'out of the way'... >> (And then add 301 redirects... ;-) >> >> Cheers! >> >> Clay Leeds @ the.webmaes...@gmail.com >> "My religion is simple. My religion is kindness." >> HH the Dalai Lama of Tibet >> -- pascal
