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

Reply via email to