RE: Having all the sitemaps in one directory

[Piroumian Konstantin <KP...@protek.com>]

People, please, don't get me wrong!
I am not proposing to change anything in Cocoon nor *force* people to do it
in their projects. I just wanted to hear if it is a good idea for the
described (Forrest) case and is there a better solution.

Let me explain one more time. 

* Prerequisites:
	- Forrest is intended to build the whole xml.apache.org site,
including sub-projects' sites & docs
	- A single sitemap is used currently for the site & docs and it will
grow as the sites get new sub-areas (FAQ, HowTo, etc.) and functionality
(statistics, calendars, news, feedback forms, etc.)
	- Forrest cannot *force* other projects to place any sitemaps inside
of their CVS repository (maybe they will have no objections, but we'll have
to convience them to do it)

* How Forrest will work
	Forrest pulls content of the target project from CVS and then builds
it (details are not defined yet) using Cocoon

* Solutions:
	1) Split the sitemap into sub-sitemaps for every functionality-area
for better maintainability then place them all in one directory in Forrest
(outside if the particular project content) and then mount them using 'src'
paths that points to correct paths inside of the content

	2) Use Ant to copy the subsitemaps to target directories inside of
the content (can be configurable for every project)

	3) Leave as it is: a single huge sitemap

	4) Ask for every project to provide its own sitemaps

So, the new question is: what are your opinions on the above solutions.

Konstantin

P.S. Sorry for cross-posting, I think it can be also interesting to Forrest
people that are not subscribed to cocoon-dev.

> From: Andrew C. Oliver [mailto:acoliver@apache.org] 
> 
> Agreed...  I like the mountable sitemaps concept..
> 
> Andy Lewis wrote:
> 
> >Uh...please don't do this....
> >
> >I'm with Stefano - keep it relocatable. Putting them all 
> together will dramatically change the way
> >coocon must be set up and managed.
> >For example - on the NASA Kennedy Space Center portal I'm 
> syndicating a sitemap with each ICE
> >package (representing a channel, content area, portlet, or 
> whatever term you like), and then
> >automounting them on the subscribing server. As it stands 
> now, this works out great. This gives me
> >huge flexibility on what I can syndicate (database apps 
> using the SQLTransformer, JSPs even), and
> >makes distribution very simple.
> >
> >
> >
> >  
> >
> >>Piroumian Konstantin wrote:
> >>    
> >>
> >>>Hi colleagues!
> >>>
> >>>An idea just came to me: what if all the sitemap files 
> where located under the WEB-INF
> >>>directory and be mounted from the one that is called 
> 'sitemap' (or configured on xconf)? So,
> >>>there can be:
> >>>        sitemap.xmap - the root sitemap
> >>>        samples.xmap - samples sub-sitemap
> >>>        docs.xmap - documentation sub-sitemap
> >>>
> >>>This can serve for two purposes: better security (it's 
> said that WEB-INF is the most secure
> >>>place in webapp context) and better managebility.
> >>>
> >>>E.g. for Forrest I definitely see a need for sub-sitemaps, 
> otherwise we will end up with a
> >>>huge and messy sitemap, but as Forrest should pull 
> documentation from multiple projects (from
> >>>CVS) which does not contain any sitemaps, so we are stuck 
> to a single sitemap.
> >>>
> >>>What do you think? Is it possible now? This should be as 
> simple as using another name (not
> >>>'sitemap') for the subsitemap and specify the needed 'src' 
> in map:mount. Am I right?
> >>>      
> >>>
> >>-1
> >>
> >>The fact that sitemaps are 'relocatable' allows people to 
> give different access control to
> >>different parts of the URI space. Placing them all in one 
> directory forces more overlap between
> >>the various sitemap managers of the variuos places of the URI space
> >>
> >>NOTE: nothing stops you from moving all your sitemaps in 
> one location *NOW*, but I don't want
> >>to force people to do it.
> >>
> >>--
> >>Stefano Mazzocchi      One must still have chaos in oneself to be
> >>                         able to give birth to a dancing star.
> >><st...@apache.org>                             Friedrich Nietzsche
> >>--------------------------------------------------------------------
> >>
> >>
> >>------------------------------------------------------------
> --------- To unsubscribe, e-mail:
> >>cocoon-dev-unsubscribe@xml.apache.org
> >>For additional commands, email: cocoon-dev-help@xml.apache.org
> >>    
> >>
> >
> >
> >  
> >
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>