Jorg Heymans wrote:
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.
Why would they be explicitly excluded? From my experience that only
happens when you specify -Dmaven.test.skip.
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
blocks.
One thing that we have found as a benefit with maven 1 is to have a
"master" build.properties 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.
OK. Does that mean that the core has to have all the dependencies that
all the blocks have even if it doesn't use them directly? That would be
silly.
Ralph
