Return-Path: 
 <cocoon-dev-return-24139-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 55711 invoked by uid 500); 12 Mar 2002 22:47:31 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 55559 invoked from network); 12 Mar 2002 22:47:30 -0000
Message-ID: <3C8E78DA.985DBBA6@apache.org>
Date: Tue, 12 Mar 2002 22:53:30 +0100
From: Stefano Mazzocchi <stefano@apache.org>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [PROPOSAL] Reducing the size of the build - ease use of optional
 components
References: <006001c1c511$58e9d580$670004c0@PC103>
 <3C86B9BE.6E99521C@apache.org> <02031109042706.03490@igacer>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

David Crossley wrote:
> 
> Stefano Mazzocchi wrote:
> > Nicola Ken Barozzi wrote:
> > >
> > > I was about to commit the POI stuff, but then I felt a bit uneasy with how
> > > the current build is organized.
> 
> <snip/>
> >
> > > 3. Structure the build as in Centipede or Forrest by using external
> > > entities, by dividing the build targets in many .xpart files. Forrest has an
> > > example of this in CVS.
> >
> > I don't like this, we should stay away from entities as much as
> > possible.[also true for forrest, I'd love that to be changed]
> >
> > What do others think about this?
> 
> Why do you say "stay away from entities"? Are saying
> take away the ability for one XML document to declare
> and include another document/fragment? Or are you
> meaning the ability to define a piece of re-usable text?

Both. I don't like entities. I pray for a day when XML 2.0 will remove
the notion of DTDs altogether. All inclusion should be performed with
xinclude and an xpipeline definition.... but this is Sci-Fi for now.

I personally never liked books done like this

 <book>
  &chapter1;
  &chapter2;
  &chapter3;
 </book>

this is the SGML way, it's old and ugly and, besides, I consider
entities a huge hack that got sedimented too much.

> The term "entity" is often misused and used to mean
> many different things. So i will wait until you explain
> and provide reasons.

I'm pretty sure we disagree on this and I agree with you that currently
there is nothing sufficiently expressive to allow people to use XML and
avoid using entities.
 
> I actually like Ken's proposal. It uses the power of XML
> to provide a very clean build configuration. It pulls
> the separate pieces together, rather than have one
> monolithic build.xml which has become cumbersome.

I agree with the fact that 75Kb of build.xml are probably the most
complex build file ever in the history of Ant and this is clearly not a
good thing.

At the same time, I'm afraid of fragmenting the pieces too much.

Oh well, I'm +0 on this anyway.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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