On 12 January 2013 18:27, Olivier Lamy <ol...@apache.org> wrote: > 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 would start by doing manual import; redeployment is extremely unlikely to recreate all the required files. For example historic Javadoc won't be recreated. If the import is done using svnmucc it is relatively quiet as far as the log messages are concerned. >> >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
