cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: [C2][RT] Component packaging system
Date Mon, 16 Jul 2001 19:19:56 GMT
I agree with you, we definitely need a way to specify new components
outside of Cocoon. The problem right now seems to be quite complex, as
you need to add the new component not only in the sitemap, but also in
Roles.java and cocoon.roles.

The same problem exists with logicsheets, which need to be specified
to cocoon.xconf. Another problem is that currently the XSP developer
that uses a logicsheet needs to know the dependency graph of all the
logicsheets the logicsheet depends on. This is flawed and we need to
correct it.

And yes, I do agree with you that CPAN is a very nice system for
distributing new components. I especially like the part about
recording the dependency not only on given packages, but also on
specific versions of them.

Regards,
Ovidiu

-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
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)

On Mon, 16 Jul 2001 15:08:14 +0100, Sergio Carvalho <sergio.carvalho@acm.org> wrote:

> Hi,
> 
> Following Berin's habits of publishing seeds for public brainstorming, I'd like 
> to hear your feelings about the need for component packaging in C2.
> 
> A look at the evolution of the stock sitemap.xmap reveals a growing number of 
> components. This is natural, and is a Good Thing(tm). C2 users are adapting 
> C2 to a growing number of demands, and this is one of the paths to do it. 
> It is just expectable that, as the user base grows, and C2 API stabilizes, more 
> and more C2 components see the daylight.
> 
> I see one problem, though. Currently, all components become part of Cocoon's codebase.

> This somewhat increases C2 complexity for developers, but unquestionably raises 
> management problems. 
> 
> When it comes to componentized development, I like to think of a CPAN like scenario.

> Among perl's many virtues and defects, one undisputed excellent feature is the
>  component repository. If an architecure has the ability to be extended through 
> components, I think it should aim to have its own CPAN: distributed development and
> testing of components, with easy deployment mechanisms and a central component 
> registry.
> 
> If C2 ever reached the number of components perl has today, the number of commiters 
> would be astonishing, and codebase management (permissions, QA, etc) would be a 
> nightmare. Clearly, if the objective is to have a large number of components, 
> components should be easily detachable from core cocoon.
> 
> What would a component packaging system require? I guess an existing packaging format

> may be reusable for these needs. A component-contained configuration might be needed.

> Here I don't have a formed opinion, other than thinking component declaration shouldn't
>  be in the sitemap. Please kick in and write back.
> 
> --
> Sergio Carvalho
> ---------------
> sergio.carvalho@acm.org
> 
> If at first you don't succeed, skydiving is not for you


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message