cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicola Ken Barozzi" <nicola...@apache.org>
Subject Re: [PROPOSAL] splitting Cocoon
Date Thu, 11 Apr 2002 06:36:57 GMT
From: "Vadim Gritsenko" <vadim.gritsenko@verizon.net>



> > From: ovidiu@orion.rgv.hp.com [mailto:ovidiu@orion.rgv.hp.com] On
> Behalf Of
> > Ovidiu Predescu
> >
> > On Wed, 10 Apr 2002 17:27:40 -0400, "Vadim Gritsenko"
> > <vadim.gritsenko@verizon.net> wrote:
> >
> > > > From: ovidiu@orion.rgv.hp.com [mailto:ovidiu@orion.rgv.hp.com] On
> > > Behalf Of
> > > > Ovidiu Predescu
> > > >
> > > > Folks,
> > > >
> > > > During the development of Schecoon I really enjoyed the fast build
> > > > time I would get compared to building Cocoon. On my machine doing
> a
> > > > "./build.sh -Dinclude.webapp.libs=true webapp" from scratch in
> Cocoon
> > > > takes 2 minutes and 10 seconds. In Schecoon a "./build.sh webapp"
> > > > takes 25 seconds to complete.
> > >
> > > If you simply skip <jar/> step in the "webapp" target this alone
> saves
> > > lots of time. I have ./build/cocoon/webapp deployed in the tomcat
> and
> > > have a patched build.xml:
> > >
> ...
> > >
> > > Why not just add intermediate target, something like "webapp-dir"?
> >
> > Even with this trick, the time taken just to verify all the
> > dependencies across all of Cocoon is too high.
>
> At least something and can be done fast...

Reslove dependencies?

Copy to the build only the java classes that make the core and build that,
then copy the functional part you want and build that.

> > Besides the point of having functionality grouped in a directory is
> > that's easy to see what are all the files used to implement it. If
> > they are put together in the same bucket is a lot harder to figure
> > out.
>
> Yup. Can't disagree.

Sorry, but I do disagree.

The basic unit of software development is the CVS module.
A module is a contained unit of software.

If there is sufficient different functionality, the module should be split
in other modules.
If not, it's better that all developers have a view of what is happening.

Moving the classes in subdirectories is *not* going to eliminate
dependencies.

If it's the build time that concerns you, there is no need to separate the
directories to have multiple targets, because modules will eliminate this
problem anyway, or clever compilation targets.

Finally, the separation of scratchpad in indipendent units was not agreed
upon: is there a reason why this proposal would pass?

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message