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: HAPPY NEW YEAR
Date Wed, 02 Jan 2002 22:25:10 GMT
Happy New Year all!

On Fri, 28 Dec 2001 17:50:59 +0100 (CET), giacomo <giacomo@apache.org> 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.

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

> 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.

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 can move things on branch
of the main trunk, but then I would have to worry about merging back
and forth. 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.

Greetings,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://orion.rgv.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)

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


Mime
View raw message