First, this mail is rather long but everybody who works with trunk (or wants to
work with it again) should read it!!! There are some changes and a couple of
questions and TODOs which can't be solved by me (alone).
What did I change:
~~~~~~~~~~~~~~~~~~
As proposed, I split up trunk into
- blocks
- blocks-tobeconverted
- commons
- core
[- site]
- tools
_blocks_ contains all blocks that already follow the new structure of
src/main/java (sources) and src/main/resources/COB-INF (samples) and
src/main/resources/META-INF/legacy (configuration files).
_blocks-tobeconverted_ cntains all blocks that have already been mavenzied but
don't follow the new structure. They require some more work.
_commons_ contains all the stuff that we need for distributions and general
stuff like logo, awards, etc. This will be the home directory of the Maven
assembly configurations that describe our future binary distributions.
_core_ contains the core stuff and the blocks-fw. I'm sure that core can be
split up into more blocks so that it gets even slimmer.
_site_ doesn't exist ATM. I will be filled with a Maven 2 module that contains
our core stuff. (my next task is providing a DaisyMojo as discussed two weeks
ago)
_tools_ contains all modules that are used to develop *with* Cocoon or stuff
that we use to e.g. generate our documentation. You'll also find there our
archetypes Currently this is only the blocks-archetype but another archtetype
will be useful that creates a minimal webapp module.
- o -
What's next?
~~~~~~~~~~~~
Checkout trunk from SVN and run
$ mvn install -Dmaven.test.skip=true
from the root directory.
Then, if you use Eclipse, call
$ mvn eclipse:eclipse
and create the Eclispe project descriptors.
Next step is getting familiar with the new directory structure and where to find
which module.
And, as I mentioned several times in the past, if you're not familiar with Maven
2, follow their tutorial which is a good starting point
(http://maven.apache.org/guides/getting-started/index.html).
- o -
I also created a directory "attic". It contains all the stuff that doesn't seem
to be useful any longer. Please, review this. I will delete the folder on April,
30th. This should be enough time for everybody. Also have a look the things in
whiteboard. I guess there is a lot of outdated stuff there too.
Btw, the size of trunk was reduced from 214mb to 129mb.
- o -
The blocks conversion script by Andreas was very helpful and certainly saved a
lot of time. One thing that we would need is a script that moves all resources
from src/main/java to src/main/resources. Could some bash-guru out there take
care of it please?
- o -
Here is a list of blocks that are special to some extend:
hsqldb: It contains the database. How do we deal with it in the future?
javaflow: It contains a compile directory. I've no idea whether we need it any
longer.
scratchpad: Contains garbage and javacApi. Garbage could be its own block and
javacApi is the first implementation of the compiling classloader by Chris
Oliver, IIRC and should be completly replaced by commons-jci IIUC.
(there might be more but these where the warnings/errors produced by the
conversion script)
If you convert one of these blocks, please find some solution for them.
- o -
Because of the new structure in trunk, I had to work on the Maven build system.
Currently it builds
- cocoon-core
- cocoon-webapp
- cocoon-forms
- cocoon-block-deployer
All other modules are commented out ATM. If you are familiar with a particular
block, try to uncomment it (either to blocks/pom.xml or
blocks-tobeconverted/pom.xml) and build it. Three things you should be aware of:
- I used the version "x-SNAPSHOT" for all pom-modules. Pom-modules are modules
that don't generate an artifact but are only used within the build system.
I used the "x" as version to show that this is *not* a usual version number.
Up-to-now the version number was 2.2.0 which isn't correct as we can start
to have separate release cycles for modules soon!
Though I'm not sure if this is a good idea to use a letter and not a number.
Jorg (and others), WDYT? Would something like "x1" be better? I wonder
what reasons could cause a version number change there ...
For consistency we should use this pattern also for the pom-modules that
are collections for impl/sample/mocks, WDYT?
- Please use 3-digits version numbers for blocks. Unfortunatly I created
2-digits version numbers for all converted blocks and noticed my mistake
too late :-(
As you have to touch pom.xml anyway, there shouldn't be too much overhead.
- Blocks in 'blocks-tobeconverted' are the manually converted blocks and
don't follow the structure yet. After changing the structure, please move
them in the repo into /trunk/blocks.
- o -
One very important thing: Can somebody take care of the unit-tests of
cocoon-core? I got 79 errors and 2 failurs. Either we throw the failing tests
away or fix them. Carsten, WDYT?
I want to use Continuum for continous integration very soon so that we see
incompatible changes very soon.
- o -
Thanks for reading so far :-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
