cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Date Thu, 03 Jan 2002 08:20:56 GMT
On Wed, 2 Jan 2002, Ovidiu Predescu wrote:

> Happy New Year all!
> On Fri, 28 Dec 2001 17:50:59 +0100 (CET), giacomo <> wrote:
> > On Fri, 28 Dec 2001, Carsten Ziegeler wrote:
> >
> > > I really enjoy being in this community and hope that the next year
> > > will be as interesting as this year.
> >
> > I'd like to say that most of us are here just because of the great
> > community we have (not only because of the great Cocoon).
> We sure are!
> > > I'm offline for the next days, but I will be back on wednesday.
> >
> > I'm not. I'd like to have all committers check in their pending stuff as
> > I'd like to restucture the directories as proposed a while back in the
> > next few days. It will be much easier for you to have it in the CVS now
> > and have me to move them around as if you have to do it afterwards.
> >
> > I'd also like to minimize the jars we have in cvs and thus propose we
> > should have only ONE lib directory in the scratchpad area containing
> > jars which are newer (usually developers version) of what we already
> > have in the regular lib directory or are new and necessary for
> > scratchpad stuff.
> Perhaps we should use CVS branches instead of placing things in a
> single lib/ directory in the scratchpad. This way each branch can have
> its own version of the libraries it wants. This is also the way CVS
> promotes concurent development.

I have not seen any jars differing from the main ones and thus I'd like
to stay in one branch.

> As a side note, the libraries you see in schecoon/lib/ were added by
> me by mistake. I will fix this ASAP.

I've seen your fix :)

> > I personally don't like to have autonomuosly compilable areas in the
> > scratchpad. They should somehow relate to what's already in the regular
> > directories.
> The only reason you see this is because I wanted to have something
> small that makes use of the existing Cocoon code, but doesn't
> necessarily need to build Cocoon for it.

I've fixed the build.xml for schecoon and will commit it RSN.

> The problem is that I need some configuration in cocoon.xconf and
> cocoon.roles to be altered, and the only way I could achieve this was
> by building things as a separate webapp.

I think that's ok as long as one finds a description how to use it.

> I can move things on branch
> of the main trunk, but then I would have to worry about merging back
> and forth.

Sure, we had this headaches for month now and are willing to give up for
a simple single branch now.

> Since the changes I'm doing do not affect Cocoon directly,
> thanks to the great componentization of Cocoon, I prefer to them as an
> extension to Cocoon.

No problem :)


> Greetings,

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

View raw message