[C2][RT] Component packaging system

[Sergio Carvalho <se...@acm.org>]

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

Re: [C2][RT] Component packaging system

[Giacomo Pati <gi...@apache.org>]

Quoting Sylvain Wallez <sy...@anyware-tech.com>:

> 
> 
> Sergio Carvalho a écrit :
> > 
> > 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
> adaapting
> > 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
> > 
> 
> 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 ;-)

Giacomo

Giacomo

> 
> -- 
> Sylvain Wallez
> Anyware Technologies - http://www.anyware-tech.com
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 
> 

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

Re: [C2][RT] Component packaging system

[Sylvain Wallez <sy...@anyware-tech.com>]

Sergio Carvalho a écrit :
> 
> 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
> 

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.

-- 
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com

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