2013/1/14 sebb <seb...@gmail.com>: > 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. So I started to manually import some propers. All old apis are now in javadocs path (just some links to fix but I prefer parent release here before doing that). Doc started: http://people.apache.org/~olamy/commons-content/site-publish.html. Feel free to improve and fix typos (I'm usually better in Moliere language than in Shakespeare one :-) ) > > 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 >
-- 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
