Daniel Fagerstrom wrote:
Joerg Heinicke wrote:
...
Ralph made a proposal [1] where exactly one block (= directory) per
block (= block in the narrower sense) exists, but with many modules
(in the maven sense) in them:
/src
/blocks
/cforms
/api
pom.xml
/impl
pom.xml
/samples
pom.xml
/test
pom.xml
This holds together all parts of one block, but provides still the
possibility to separate them.
Hope this makes it more clear,
Jörg
[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113004733610151&w=4
Although I agree with that 120 blocks in one directory is easy to get
lost in and that we have to do something about that, I see some
problems with the above proposal.
It is a good idea to separate in api and implementation, but a good
api might have several impementations. For the flow api we have
flowscripts, Java flow and Apples, IIUC. The expression api that we
discussed recently have a JXPath, Jexl and Rhino implementation.
Are these really the same API? If so then this proposal makes even more
sense. You could have a flow block that includes the api and then has
one implementation (or none). Other blocks would then not have an api in
them but there implemenation would be dependent on the other block's api
(but not the impl).
For tests Jorg have already said that Maven's test support assumes
that the tests are integrated in the module.
Maven 2 would have to be drastically different from maven 1 for this to
be true. We use the structure above with no problem. You just have the
test module dependent on the impl, which is in turn dependent on the
api. The test module has all the nice reports about code coverage
because it can actually force the compilation of the impl source within
the test module.
For OSGi it will also be easier to handle unit tests if they are part
of the bundle, otherwise all packages that we want to unit test (i.e.
all implementaion packages), need to be exported which we don't want.
I don't understand. Users of a bundle will never want the tests and all
the baggage they require. Just because a unit test is in a different
root directory does not mean it cannot be in the same java package, so
nothing is any different than if they were in the same directory. To be
clear
impl/src/java/org/apache/cocoon/generation/MyGenerator.java and
test/src/java/org/apache/cocoon/generation/MyGeneratorTest.java
are both in the same package, so MyGeneratorTest can get at package
methods within MyGenerator.
For functional tests it might however make sense to write an external
test block.
We use the same structure and put the functional tests in the same place
as the unit tests. We just name them *FuncTest and then use the excludes
in the test section of the project.xml to exclude them from a normal build.
/Daniel
Ralph
