cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Questions on cleaning up trunk
Date Mon, 27 Mar 2006 07:39:47 GMT

Andreas asked in a couple of 
questions. I will try to answer them but please add your comments in the case of 
a different opinion. Changes now are easy, after Wednesday (not Thursday as I 
wrote in my previous mails) when Andreas and I will actually do it they are much 
more difficult:

* Agree on a naming convention for artifact ID suffixes (singular vs. plural): 
e.g. *-mocks, *-impl, *-sample

fine for me.

* What happens with the following dirs within cocoon trunk: lib, misc, src, tools?

lib: remove it
misc: goes into trunk/common
# confpatch/    remove it - replaced by Maven build
# deprecated/   remove it - things deprecated in 2.1.x are not necessary
                             in trunk, right?
# osgi-servlet/ remove it - replaced by blocks-fw-osgi-impl
# resources/    no idea   - if nobody speaks up till Wednesday, we will
                             remove them
# samples/      remove it - old or duplicates
# schema/       remove it - outdated
# test/         remove it - Anteater tests: in branch we have a working
                             httpunit environment. needs to be ported

* Why are databases and xmldb in directory blocks as well as inCocoon trunk?

probably the person who moved them forgot to delete them. Jean-Baptist, wasn't 
it you who did the move? If yes, can we delete them in /cocoon/blocks?

* What happens with scratchpad? Still needed?

yes unfortunatly there is some valuable stuff there, e.g. the caching source

* What's the right version for cocoon-core dependencies: 2.2.0-SNAPSHOT or 

2.2.0-SNAPSHOT - we should use the 3-digits pattern IMO

* How should the 'mocks' directory be mapped to the new directory structure?
   - Solution 1: Map to cocoon-<block>-mocks/src/main/java (separate artifact)
   - Solution 2: Map to cocoon-<block>-impl/src/mock/java (not a standard Maven 
way I think - currently used for the JSP block)
   - Solution 3: Include them in cocoon-mocks/src/mock/java (possibly prefered, 
since it already exists?)
   - Solution 4: May have to be mapped manually (see

If mocks are specific for a particular block, we should put the classes into a 
separate module. How do we express the dependency so that it compiles with the 
mocks but runs with the implementation?

* Add 'name' tag to each POM in a consistent way:
   - parent POM: <name>
   - impl POM: <name> Implementation
   - sample POM: <name> Samples
   - mock POM: <name> Mocks


* Copy/move status.xml
   - There are some inconsistencies for the current new blocks
   - Some are located in the parent block, some in the impl block
   - Where should they be located?
   - May there be more than one? e.g. for impl, sample, ...

Put status.xml into the impl module as for them we will create the documentation.

Here some more files that need to be moved:

# CREDITS.txt - Where do we need them? For the distribution?
                 For now I'd put them into the trunk/commons directory
                 Thinking more about this, I propose to configure
                 the assembly plugin for commons so that we can
                 build distribution packages from there.
# DESKTOP.INI - remains where it is
# INSTALL.txt - move to trunk/commons
# KEYS        - move to trunk/commons
# LICENSE.txt - move to trunk/commons
# NOTICE.txt  - move to trunk/commons
# README.blocksmode.txt - remove it (outdated)
# README.m10n.txt - leave it where it is
# README.osgi.txt - remove it (outdated)
# README.txt - move to trunk/commons
# TO-SYNC-FROM-BRANCH.txt - leave it
# announcement.xml - move to trunk/commons

Anything else that needs to be considered by Andreas and me?

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}



Telefonate ohne weitere Kosten vom PC zum PC:

View raw message