Jorg Heymans wrote:
Hi all,
I've just committed an example of how our repository could be structured
to support the ongoing componentization, new (osgi) block structure and
M10N. Daniel suggested this flat structure a while ago [0], maven [1]
and eclipse [2] use a similar layout.
The example is in the whiteboard, under maven2/cocoon-flat-layout.
The concept is the following :
/trunk
pom.xml
/cocoon-core
/cocoon-forms-block
/cocoon-ajax-block
/cocoon-asciiart-block
/... other blocks
/webapp
Looks good.
--> pom.xml
This is essentially just a multi-module pom which acts as the parent of
all module poms.
<module>cocoon-core</module>
<module>cocoon-ajax-block</module>
<module>cocoon-forms-block</module>
....
It allows us to define properties and plugins valid for all modules.
Child modules can still override if necessary.
--> /cocoon-core
This is kept as one maven module for now, we can choose to split this up
further. I didn't separate this one into api/impl as I wasn't sure if it
made sense, but maven-wise it's very easy to do so.
--> /cocoon-forms-block, /cocoon-asciiart-block ...
All modules that we choose to host and support ourselves land in the
repository root.
Does the block suffix buy us anything? Everything, core included will be
a block.
We can either stick to the existing block naming
convention or go for a package based approach like eclipse.
AFAIU either will do, so we could as well stick with the existing name
convention.
...
/Daniel
