cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: [proposal]
Date Thu, 21 Jul 2011 18:54:06 GMT
On 07/19/2011 12:17 AM, Sylvain Wallez wrote:
> Le 18/07/11 20:56, Reinhard Pötz a écrit :
>> On 07/13/2011 09:30 AM, Steven Dolg wrote:
>>> We should take a look at introducing "topic" specific modules.
>>> I fear that the optional module turns into a giant clump of all things
>>> unrelated.
>> Generally +1 to topic specific modules. As Steven already knows from
>> Indoqa projects, I'm a fan of many small modules ;-)
>> In regard to the still small C3 community (not in terms of people but
>> rather in terms of SVN changes and mailing list activity) we should
>> think about having a "Cocoon Stuff" project (analogous to Wicket
>> Stuff) where everybody that is interested gets commit rights. This
>> also clearly indicates what we as Apache Cocoon community consider
>> being officially maintained.
>> (BTW, the Wicket community is very restrictive in moving code from
>> into the wicket-core codebase because of the mentioned
>> maintenance reasons).
>> The wicket folks had a vote between hosting their stuff project either
>> at Github or at Apache-Extras (powered by Google Code). Github won and
>> the result can be found at and
>> But there is also a downside:
>> - Cocoon release will become (slightly) more work in the future
>> because two code bases have to be released
>> - releases are not ASF releases and we can't
>> rely on the ASF litigation protection mechanisms anymore
>> (which is also true for most opensource software out there)
>> (NB: That is the reason why we need 3 +1 votes of PMC members before
>> we can do a release and tag it with the Apache name)
>> - that the transition has to be done:
>> * contact the Apache Board about reserving the domain
>> * decide what goes to and what remains at
>> * rename all packages accordingly
>> * create a cocoonstuff-samples module
>> * decide whether we (the Cocoon PMC) want to enforce the AL 2.0 for
>> all cocoonstuff modules
>> * decide about the release voting precedure
>> * setup a website (if we use Github we could also use
>> it for hosting static websites)
>> * find out how to get the Maven artifacts deployed to the
>> central Maven repository
>> * find a solution for continuous integration (Jenkins) and providing
>> snapshot releases (Nexus?)
>> But IMO there is also an additional benefit: Creating cocoonstuff
>> would lower the barrier for contributions and could attract more
>> people to get involved with C3.
>> WDOT?
> Hmm...
> I definitely agree that modules specific to a 3rd party library or a JSR
> that's not included in the JDK are to be packaged as separate artifacts.
> As Steven rightfully points out, it's a real pain to download and
> package a huge load of libraries you don't need. And this what has been
> done in Cocoon since 2.0 with the large collection of blocks.
> Now hosting these modules away from is a different thing that
> has strong implications on community dynamics. The C3 community is
> slowly growing after having been almost dormant for months (years?),
> which is a very good thing, and I fear that a would just
> harm this nascent effort by splitting the still brittle community. Also,
> a separate environment comes with additional time spent in
> administrative stuff (look at your long task list!) that could probably
> be used more wisely to build a stable C3.
> So if the purpose is to lower the barrier for contribution, then why not
> just having a "contrib" directory in SVN, clearly showing that these
> aren't core modules, but still under the oversight of the PMC and the
> ASF at large?
> Of course, managing Git pull requests would be more convenient than
> applying patches in Jira, but still, at this point, this is probably
> easier than having a completely separate infrastructure.

After reading Torsten's and your comments I agree that setting up is too early.

Nevertheless C3 already counts more than 20 subdirectories which is 
discouraging for people that want to get familiar with the code base. 
Especially if you don't need all the webapp/REST stuff you only need 
cocoon-pipeline, cocoon-sax, parent and maybe cocoon-optional.
One could say that this problem can be solved with good documentation 
but the psychological barrier doesn't go away.

Maybe it would be good enough to restructure the directory tree so that 
everybody can decide what he needs:

cocoon3/trunk/pipeline ..... plain Java pipelines
cocoon3/trunk/sitemap ...... sitemap implementation (currently only the
                              XMLSitemap impl)
cocoon3/trunk/webapp ....... using C3 for web applications
cocoon3/trunk/[stuff]* ..... all additional stuff that is clearly
                              marked as not being ready for prime time

(*) needs a better name

I don't know what to do with

  . documentation (split it into the three sections or have one central
  . the parent POM (one for each section or one global parent POM.
    However, one parent POM has the disadvantage, that you couldn't
    just checkout
    which isn't ideal IMO)
  . the archetypes (should probably go to the webapp section)

but this could be decided if others agree that the global direction of 
my proposal is useful.

Reinhard Pötz         Founder & Managing Director, Indoqa and Deepsearch

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

       Furthermore, I think Oracle has to honor the JSPA agreement.

View raw message