cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans>
Subject Re: [M10N] separating samples from blocks
Date Sun, 23 Oct 2005 10:42:13 GMT

Ralph Goers wrote:

> I don't like this structure much.  I prefer
> /src
>    /blocks
>              /cforms
>                   /api
>                        pom.xml
>                   /impl
>                        pom/xml
>                   /samples
>                        pom.xml
>                   /test
>                        pom.xml
> Some blocks might only have an api or an impl and that is ok.  Having a
> separate test module has several advantages; it is easy to find the
> tests, it is easy to run them (or not if you don't want to), it is easy
> to separate them out, and it encourages folks to actually create tests
> since it is very obvious when you don't have any

Separating the tests in a separate module is dangerous because they are
explicitly excluded from the main build cycle - guess how often they
will get run then. Maven has built-in support for managing tests, i
think we should leverage this and not go against it.

Keeping api and impl apart is a good thing, but I'll first focus on
getting the samples separated. We could however suggest this structure
already in the block-archetype, if that's how we want people to build

> One thing that we have found as a benefit with maven 1 is to have a
> "master" file that contains all the versions of the
> dependencies - the project.xml files only specify the artifact and not
> the verison. This makes sure that all the subprojects are all using the
> same versions. That could become a significant problem with all the
> blocks Cocoon has if the core project doesn't control the versions.

In maven2 you can have a dependency on a project. ATM all blocks depend
on the cocoon-core block/project so if we bump a library's version
number there it automatically trickles down to all blocks.


View raw message