cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephan Michels <step...@apache.org>
Subject RE: [CLEANCOON] Let's clean Cocoon and modularize it (was: Cocoon Organization (Cocoon plugins))
Date Tue, 06 Aug 2002 07:30:56 GMT

On Tue, 6 Aug 2002, Carsten Ziegeler wrote:

> Stephan Michels wrote:
> >
> > On Tue, 6 Aug 2002, Christian Haul wrote:
> >
> > > On 06.Aug.2002 -- 08:32 AM, Carsten Ziegeler wrote:
> > > > So, *if* we vote on refactoring or starting a new Cocoon
> > > > major version, I'm definitly -1 on this.
> > > >
> > > > I still believe that we can solve some (perhaps not all)
> > > > problems simply by organizing our project structure and
> > > > by shifting our activities from "hacking new features"
> > > > to "making a more perfect solution".
> > >
> > > So, could we just come back to Berin's original idea, create some
> > > subdirectories based e.g. on functionality, move stuff to
> > > subdirectories if appropriate, and change the build process to include
> > > these subdirectories as we do with scratchpad?
> > >
> > > Step two could be to build seperate jars, step three to relax release
> > > cycles for sub-projects. No magic, no changing of any names, just
> > > re-packaging.
> > >
> > > Candidates so far:
> > >
> > > * forms (simple and XML)
> > > * databases (esql, transformer, actions)
> > > * fop
> > > * portal
> > >
> > > How about (in addition to the above):
> > >
> > > * delhi
> > > * docbook
> > > * ...
> >
> >
> > Why do we need sub directories? I like Andrew's idea with the xconfig.
> > All we need some more properties for the buid file.
> >
> > .ant.properties.minimal:
> > include.forms=no
> > include.databases=no
> > include.fop=no
> > [...]
> >
> > .ant.properties.full
> > include.forms=yes
> > include.databases=yes
> > include.fop=yes
> > [...]
> >
> > And the build file can exclude the files for the subprojects, similar to
> > the prepare-src-main task.
> >
> Yes, this is correct and it's (more or less) the way the build system
> is currently working - (the difference is that currently we don't have
> properties but we check for available classes).
>
> Actually this is a maintainance nightmare, Often new features were added
> and the build system (or the optional checks) were not added accurately.
> The build.xml is getting bigger and bigger. By separating this into
> directories this will be IMHO much cleaner and easier.

How should this look like?

src/java/org/apache/cocoon/modules/forms/components/*
src/java/org/apache/cocoon/modules/forms/generation/*
src/webapp/samples/forms/*

src/java/org/apache/cocoon/modules/fop/components/*
src/java/org/apache/cocoon/modules/fop/serialization/*
src/webapp/samples/fop/*
etc.

Like this? It is more cleaner, but I see directories, which owns only
one class :-|


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


Mime
View raw message