On Tue, 17 Jul 2001 11:26:58 +0200 (CEST), Giacomo Pati <[EMAIL PROTECTED]> wrote:
> Quoting Sylvain Wallez <[EMAIL PROTECTED]>:
>
> > What's really missing is a way for components to formally describe their
> > configuration. For now, the configuration is sometimes specified
> > textually in the javadoc and often you have to dig in the code to know
> > what the component expects. This would allow for verification of
> > configuration and building user-friendly assembly tools.
>
> We've started to build up our Avalon components in our company to
> have a X.role file which contains the role definition and a X.xconf
> file which contains the configuration definition for the component
> X. We have planned to build a tool/ant task to combine those
> fragments into a main roles and xconf file (depending on ant
> properties which itself may depends on the presence of some classes
> in the classpath during the build, etc.). Adding to that one can
> augment the xconf fragment with documentation tags which can be
> gathered together to build a overall configuration guide by the
> mentioned tool/task. But so far we haven't had the time to building
> that tool/task.
>
> This tool/task in fact could be usable for C2 as well as there is
> activity going on to make it more customizable (minimal C2, maximal
> C2, etc.). And also if we move the <map:components> section into the
> cocoon.xconf file this is indead very convenient to build up a
> cocooon.xconf file.
>
> Any additional thoughts or even volunteers ;-)
What I think is rather needed is a way to read the X.conf and X.role
files dynamically at runtime, without the need to append all of them
in a single file. This is along the same lines as sub-sitemaps.
The need for this appears in a totally different environment than Web
publishing, but could probably be applicable to Web publishing as
well. In my group at HP, we are looking at Cocoon2 as a framework for
building Web services (the server side), not only for accessing them
(the client side).
In this environment the notion of deploying a Web service under
Cocoon2 should be no different than deploying a new war file. A
Cocoon2 developed service should be totally contained within a war
file. This means we should be able to register all the components,
logicsheets etc. with the main Cocoon2 framework without having to
rebuild the Cocoon2 war file. The ability to register dynamically
components, transformers, generators, logicsheets etc. makes a lot of
sense.
Since all these resources become known to Cocoon2, it would be nice
for other Web services to reuse some of the resources provided by
other Web services. A packaging system that lists all the dependencies
of the package, and the things it provides, very much a la CPAN, would
be really nice.
Regards,
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://orion.nsr.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
