cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <>
Subject Re: Proposal: Inclusion of CocoBlog in scratchpad
Date Thu, 08 Aug 2002 09:41:44 GMT

On Thursday, August 8, 2002, at 10:18  am, Nicola Ken Barozzi wrote:

> Ugo Cei wrote:
> ...
> > Steven:
> >
> > > CocoBlog could be the prime example of a drop-in Cocoon application
> > > (dare I say 'block'?). If we add it to the distribution, we miss  
> the
> > > opportunity of showing off plug&play installation of a Cocoon-based
> > > app.
> >
> > The problem is I don't see a real plug&play feature coming to Cocoon
> > very soon. So we have tow options:
> >
> > a) I continue to distribute CocoBlog as a full application that  
> comes > with its own Cocoon version, just like I'm doing on > SourceForge
> > b) I distribute CocoBlog as a not-so-plug-and-play Cocoon "block"  
> and > leave it to users to plug it inside their copy of Cocoon.
> >
> > What I'm proposing here instead is
> >
> > c) we include CocoBlog in scratchpad and when we get blocks, we
> > refactor it out.
> >
> > But listen, I don't want to insist too much. As I write above, I
> > have my own doubts about this move and own much of this proposal
> > to the gentle pressure of the people I quoted.
> >
> I have a solution that could make all happy.
> Let's make a cocoon-apps CVS repository that can trigger the  
> compilation of Cocoon by assuming that the cocoon2 CVS is checked out  
> in the same common dir.
> It would make it easier also for the cleanup that's gonna take place  
> soon.
> So, how does this sound?


I think the idea of a cocoon-apps area closely associated with the  
Cocoon project is essential.  The separation of apps from cocoon is  
important, but it is also important to the Cocoon project to have lots  
of apps that turn Cocoon into a quick to implement solution for a whole  
range of applications.  It makes no sense to force people to locate  
these applications in timeconsuming-to-setup separate projects.  In  
some cases it will be these apps that 'sell' Cocoon.

However (and this is a minor point).  I have a lot of frustrations with  
the configuration of the Avalon project, and one such frustration is  
the dependancy of projects upon other projects with critical namings,  
that are required to be in the same common parent directory and have to  
be built in a particular order in order to function.

Cocoon applications will be dependant upon Cocoon: I therefore suggest  
that the cocoon-apps directory should be located *inside* the cocoon  
CVS repository.


            Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck  
      Key fingerprint = 89D9 E405 F8B1 9B22 0FA2  F2C1 9E57 5AB1 88DD  
Stuart Roebuck                          
Systems Architect                             Java, XML, MacOS X, XP,  

To unsubscribe, e-mail:
For additional commands, email:

View raw message