El jue, 09-03-2006 a las 10:07 +0100, Andreas Hartmann escribió: > Thorsten Scherler wrote: > > El mié, 08-03-2006 a las 12:21 +0100, Josias Thöny escribió: > >> On Wed, 2006-03-08 at 12:10 +0100, Thorsten Scherler wrote: > >>> Hi all, > >>> > >>> should we activate the "lenyadoc" module in the default pub? > >>> > >>> I just found out that it is a module and have to be activated via > >>> publication.xconf, right? > >> Adding a module to publication.xconf is only for the menu (include the > >> module's menu entries). > >> > >> AFAIK the lenyadoc module has no menu and therefore doesn't have to be > >> included in publication.xconf. > >> > > > > Thanks. > > > > ...but that raises the doubt whether that is practical. Imagine you have > > *1 million modules*, that means all get loaded even if your pub needs > > *two*? > > What do you mean with "loaded"? A module is not loaded, it just waits in > its directory until it is called :)
;) > > The only thing that can cause memory and performance troubles is patching > cocoon.xconf. ...and deploying the java stuff from this 1 million modules. ;) > > But this raises the following issue: > Imagine you want to add new publications on run-time (IMO that should be > possible). Adding new modules on run-time won't be possible until we > have OSGi or something like that. So - you have to deploy all modules > on compile-time to make them available to publications that might need > them in the future. Good point, thanks for explaining it. :) > > > In forrest we have > > project.required.plugins=org.apache.forrest.plugin.output.pdf,org.apache.forrest.plugin.internal.dispatcher,org.apache.forrest.themes.core,org.apache.forrest.plugin.output.search > > This property is responsible which plugins (similar to modules) got > > mounted for the certain project. > > In Lenya, this is modules.root.dirs in local.build.properties. Jaein. ;) Yes and no, but I maybe I learned something where forrest can overcome some currently raising issues with plugins. ;) In lenya we use the root dir (all modules got included) in forrest we define each plugin. > > > I think we should have something similar and not mount every single > > module. > > We do have something similar - see above. > > > Imagine further there are modules that are trying to do the > > same. Which one will be taken and how to control it? > > Modules are referenced by the module name, not by their capabilities. > So there is no confusion which module will be taken. yes, right, for usecases no problem at all. ...but what about the matches in the sitemap from the modules? What happends if I define two times the same match in two different modules? Which one will be taken and how can I control it? > > > > That is why I thought that I need to declare the modules in the > > publication.xconf, which makes for me perfect sense. ;) > > No, we can't determine which modules to install based on publication.xconf > (see my first comment in this mail). Yes, but actually we cannot add new publications on run-time now, right? ;) salu2 -- Thorsten Scherler COO Spain Wyona Inc. - Open Source Content Management - Apache Lenya http://www.wyona.com http://lenya.apache.org [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
