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 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. Regards Jorg
