Andr? van Toly <[EMAIL PROTECTED]> wrote:
> > > transactionhandler.xml
> >Why did you not simply remove it?
>
> I was not sure what to do. It depends on what we
> want with the applications in the distribution.
> There are two options.
>
> The application XML Importer is part of the 1.7
> release, because it's JSP's are present in
> /mmbase/xmlimporter and it's classes in
> mmbase.jar.
Hmm, we have a xmlimport application in applications haven't we?
It think classes are (should be) present in mmbase-xmlimporter.jar, not in
mmbase.jar.
But unlike for example the
> application Community, is it's configuration file
> not present
> (/WEB-INF/config/modules/transactionhandler.xml)
> and not switched to active. Community
> (/WEB-INF/config/modules/communityprc.xml) is
> present and is active but it is missing its
> builders cause it's application was not set on
> auto-deploy.
Community application is only installed _in the distro_ because it provides
one of the examples. The module should be active, because there is no easy
way to install modules. The builders will be installed by installing the
appliction, but the module _will not_. Therefore it seems reasonable that
the module must be in the distro and also be active.
That it produces a warn then, is a bit unfortunate. It should perhaps be an
'info' message ('community module is active, but the builder are not
(yet?)').
> 1. Make these applications fully active on the
> first start of the release (setting module
> configuration files on active and applications on
> auto-deploy). That means that for example the
> community application will load and try to
> install it's builders.
I don't quite agree. There is an 'examples installation page' in
mmexamples/install.jsp which will in most cases straightforwardly install
those builders (only not when you lack write permission on file system, one
of the sad consequences of the fact that the files need to be copied), after
which the community examples will work, provided that the community module
is active. So, since there is no way to switch a module to active, we
figured that it should have been active to start with.
>
> 2. Put all the needed files for these
> applications in their appropiate configuration
> directories but make them inactive. Their JSP's,
> the documentation and the readme's in the release
> should point users to the configuration files to
> activate the applications.
I think it silly that if you click on 'deploy' for the community application
that you then still have to edit an XML and restart the app. What kind of
lame deploy is that?
I think all problems are solved if we just change the WARN of the community
module to INFO, because evidently some people get nervous of that. The
module is then active also without the builders (which is no problem, even
if you forget to remove the xml if you never going to use it), but will
become functional after installation of those, for which there is an
interface available in the admin-pages and mmexamples directory.
Of course for 1.8 we then put all our hopes on the myth of apps2, using
which it will undoublty be possible to install and activate modules in a
decent way.
Michiel
--
Michiel Meeuwissen
Mediapark C101 Hilversum
+31 (0)35 6772979
nl_NL eo_XX en_US
mihxil'
[] ()
