cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralph Goers" <>
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.


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

View raw message