cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers" <Ralph.Go...@dslextreme.com>
Subject Re: Scratchpad Dependencies
Date Wed, 10 Nov 2004 23:37:30 GMT
I know for sure that javaflow only uses ojb and forms for the samples.  I
just checked in a fix to the build to not compile the samples if
exclude-webapp-samples is true. (I thought this was checked in a while ago
but it wasn't there).  So if you specify exclude-webapp-samples you should
be able to determine what the real dependencies are.

Ralph


Daniel Fagerstrom said:
> I planed to use some stuff in scratchpad for development. As I have a
> slow computer at home I always remove all blocks that I don't need to
> decrase compile time and startup time.
>
> The tree below describe everything that the scratchpad block depend on.
> And this is without samples dependencies. 18 dependencies!!!
>
> scratchpad
>    axis
>    cron
>    faces
>      portal
>        authentication-fw
>          session-fw
>            xsp
>        html
>        session-fw
>          xsp
>      taglib
>    javaflow
>      forms
>      ojb
>        databases
>          xsp
>    repository
>      databases
>        xsp
>      eventcache
>        jms
>          hsqldb
>    velocity
>    xsp
>
> Hopefully some of them are just sample dependencies and can be removed.
> I have no fancy IDE, so I didn't succeed in tracking down all the
> dependencies. Especially I wonder about the dependency on faces, where
> comes that from?
>
> But anyway the scratchpad start to become quite heavy. IMHO there are a
> lot of things in the scratchpad that would suit better as unstable
> blocks e.g. Garbage, the Cocoon Ant task, caching source, flow
> webservices, groovy, sitemap viewer and maybe some more.
>
> Maybe there are some components that could graduate to core and some
> other that never lead anywhere and can be removed.
>
> IMHO the scratchpad block should mainly be for isolated components that
> preferably only depends on core. As soon as there are a number of
> components that cooperates or have some common theme or introduces a lot
> of dependencies, they would better be packaged as a block, IMHO.
>
> Maybe we should have a special directory for scratchpad blocks. Or maybe
> we could even have some mechanism that would make it easy to use
> scratchpad blocks that lives in the whiteboard directory.
>
> WDYT?
>
> /Danielf
>
>


Mime
View raw message