You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Thorsten Scherler <th...@wyona.com> on 2006/03/08 12:10:56 UTC
Activating "lenyadoc" module in default pub?
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?
TIA for any information.
P.S.: will update the docs if somebody can verify that one have to add
the module to the publication.xconf.
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Activating "lenyadoc" module in default pub?
Posted by Andreas Hartmann <an...@apache.org>.
Thorsten Scherler wrote:
[...]
>> The only thing that can cause memory and performance troubles is patching
>> cocoon.xconf.
>
> ...and deploying the java stuff from this 1 million modules. ;)
Thanks to dynamic class loading this is only a compile-time performance
issue.
[...]
>>> 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.
That would be OK with me, I guess it would simplify the build process.
>>> 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?
Hmmm, I don't quite understand ...
You call the module explicitely using its name, so why should there
be two modules which could be called?
cocoon://modules/<module-name>/...
>>> 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? ;)
We can: localhost:8888/index.html -> "New publication"
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Activating "lenyadoc" module in default pub?
Posted by Thorsten Scherler <th...@wyona.com>.
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
thorsten.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Activating "lenyadoc" module in default pub?
Posted by Andreas Hartmann <an...@apache.org>.
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.
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.
> 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.
> 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.
> 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).
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Activating "lenyadoc" module in default pub?
Posted by Thorsten Scherler <th...@wyona.com>.
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*?
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.
I think we should have something similar and not mount every single
module. Imagine further there are modules that are trying to do the
same. Which one will be taken and how to control it?
That is why I thought that I need to declare the modules in the
publication.xconf, which makes for me perfect sense. ;)
salu2
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Activating "lenyadoc" module in default pub?
Posted by Josias Thöny <jo...@wyona.com>.
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.
Josias
>
> TIA for any information.
>
> P.S.: will update the docs if somebody can verify that one have to add
> the module to the publication.xconf.
>
> salu2
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org