2013/1/11 Olivier Lamy <ol...@apache.org>: > 2013/1/11 sebb <seb...@gmail.com>: >> On 11 January 2013 17:29, Olivier Lamy <ol...@apache.org> wrote: >>> 2013/1/11 sebb <seb...@gmail.com>: >>>> On 11 January 2013 16:22, Olivier Lamy <ol...@apache.org> wrote: >>>>> 2013/1/11 sebb <seb...@gmail.com>: >>>>>> On 11 January 2013 14:32, <ol...@apache.org> wrote: >>>>>>> Author: olamy >>>>>>> Date: Fri Jan 11 14:32:58 2013 >>>>>>> New Revision: 1432062 >>>>>>> >>>>>>> URL: http://svn.apache.org/viewvc?rev=1432062&view=rev >>>>>>> Log: >>>>>>> redirect for attributes >>>>>>> >>>>>>> Modified: >>>>>>> commons/cms-site/trunk/content/resources/.htaccess >>>>>>> >>>>>>> Modified: commons/cms-site/trunk/content/resources/.htaccess >>>>>>> URL: >>>>>>> http://svn.apache.org/viewvc/commons/cms-site/trunk/content/resources/.htaccess?rev=1432062&r1=1432061&r2=1432062&view=diff >>>>>>> ============================================================================== >>>>>>> --- commons/cms-site/trunk/content/resources/.htaccess (original) >>>>>>> +++ commons/cms-site/trunk/content/resources/.htaccess Fri Jan 11 >>>>>>> 14:32:58 2013 >>>>>>> @@ -5,6 +5,7 @@ RedirectMatch ^(.*)/exec/(.*) $1/propers >>>>>>> RedirectMatch ^(.*)/cli/(.*) $1/propers/commons-cli/$2 >>>>>>> RedirectMatch ^(.*)/ognl/(.*) $1/propers/commons-ognl/$2 >>>>>>> RedirectMatch ^(.*)/digester/(.*) $1/propers/commons-digester/$2 >>>>>>> +RedirectMatch ^(.*)/attributes/(.*) $1/propers/commons-attributes/$2 >>>>>> >>>>>> Could these use Redirect instead? >>>>> Sure for live target will work but not for testing here >>>>> http://people.apache.org/~olamy/commons-content/ >>>>>> >>>>>> Also, why does the path include "propers" rather than "proper" as used >>>>>> elsewere in commons SVN? >>>>> >>>>> Ah yes could be better. >>>>> As I used dormant-sites and sandbox-sites maybe proper-sites WDYT ? >>>> >>>> What is the point of having both? >>>> >>>> dormant/ >>>> dormant-sites/ >>>> >>>> The existing c.a.o website uses just >>>> >>>> dormant/ >>> currently dormant has a content generated by cms (index.html). >>> So adding content in this directory not generated by the cms mechanism >>> will mean adding paths in ext paths file to avoid deletion. >>> This mean adding: >>> * dormant/cache >>> * dormant/clazz >>> * etc.. (one line per sub project deployed manually or via the scm >>> publish maven plugin) >> >> It seems silly to have a directory for a single file. >> Why not rename the index file and move it to the top level? > I agree. > > Maybe same for sandbox ? done > and moving gsoc directory on top level ? done > > changing propers to proper. done. See result here: http://people.apache.org/~olamy/commons-content/
Now what do we do with proper content ? manual import from people or redeploy sites from trunk of each ? > > I have a bit of time for that. > Let me know. > >> >>> And furthermore such path is not supported by cms for exclusion (lines >>> in extpaths file must be depth one only or I missed something) >>> >>>> >>>> There is currently no proper/ directory, as the proper component sites >>>> are at the top-level. >>> same explanation as for dormant and extpath content. >>> If you still want commons.a.o/lang commons.a.o/math this will need one >>> line per path in ext paths file. >>> By experience I see that too much lines in ext paths tend to slow *a >>> lot* publishing. >>>> >>>> Not sure why that cannot be maintained going forward, but if not, the >>>> minimum change would be to add a proper/ subdirectory parallel to >>>> dormant/ and sandbox/ >>>> >>>> Not having a parent proper/ directory does place some minor >>>> restrictions on component names - e.g. one could not have a proper >>>> component called "sandbox" or "css" or "images" for example - but that >>>> is not a huge restriction, and it would avoid needing to use the >>>> Redirect entries. >>>> >>>> Having said that, having a parent proper/ directory makes sense from >>>> the point of view of consistency across the 3 classes of components, >>>> so it's not critical to avoid it. >>>> >>>> But I do think having separate -sites folders is unnecessary complication. >>> see explanation above. >>>> >>>> Whatever is finally decided upon needs to be properly documented. >>> where ? in something like commons.a.o/publish-site.html ? >> >> Probably; could start by using the Wiki and move to site once complete. >> >>>> >>>>>> >>>>>> >>>>>>> #sandbox >>>>>>> RedirectMatch ^(.*)/sandbox/cli2/(.*) $1/sandbox-sites/commons-cli2/$2 >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Olivier Lamy >>>>> Talend: http://coders.talend.com >>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Olivier Lamy >>> Talend: http://coders.talend.com >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> --------------------------------------------------------------------- >>> 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 >> > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org