Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <440C58D2.40008@apache.org>
Date: Mon, 06 Mar 2006 16:44:18 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Status of block development
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

For those of you, who think that blocks will never get finished - here a short 
list on our achievments so far:

  - splitting up of the monolytic Cocoon core has started by Daniel's
    refactorings
  - we use Spring as component framework and finally got rid of ECM, Avalon, etc.
  - sitemap blocks are working
  - block deployment is working
  - trunk is mavenized
  - virtual sitemap components
  - we defined the directory structure of blocks

  - ... and probably I've forgotten this or that important point ;-)

                                     - o -

Jean-Baptiste asked, what's missing. Here are all the issues that I know of:

  - [cocoon-deployer-webapp-sample] is a very simple example. Here we need
    something more useful. We have to identify blocks that we want
    to show. I suggest
    # cforms + samples
    # ctemplate + samples
    # auth + samples
    # session-fw + samples

    Except cforms all these blocks are not shared between 2.1 and changing
    cforms shouldn't be a big problem as the cforms directories are
    references from 2.1 on a very detailed level. Right?

    I will start with the session-fw but help from others is more than welcome!
    Anybody interested?

  - rework the two tutorials so that they work completly.
    I will work on this.

  - provide an OSGi based blocks-fw (Daniel is working on this - I'm sure
    anybody who is interested in working on this too, is welcome!)

  - tool integration with M2 and Eclipse (I will work on this as soon as I
    know more about the OSGi contracts - and again, anybody who is interested in
    working on this too, is welcome!)

  - change our documentation generation process
    Every block will become a Maven project. Maven has a site:site goal can
    generate a lot of interesting reports.
    What we need is an integration of our docs in Daisy. My idea was that we
    provide a Maven plugin that reads out a navigation document, that servers as
    starting point, from Daisy and adds the docs from there to the generated
    site. The URL of the navigation document could be set as plugin parameter
    in pom.xml.

    Is anybody interested in working on this?

    I will start a separate thread on this as this mail might not be read
    by all people that are interested in our documentation process.

  - error handling (Daniel: there is sophisticated creation of error messages in
    the CocoonServlet, where is the right place for it in the blocks
    architecture)

    Is anybody interested in working on this?

  - Logging integration (Daniel: "I put it in the BlocksManager but didn't give
    it much thought")

    Is anybody interested in working on this?

  - Multi part MIME handling (Daniel: "not part of the blocks architecture to
    simplify things, would make most sense to put in a ServletFilter IMO")

    Is anybody interested in working on this?


As you can see, the list of open points is finite and the point of a first 
preview release isn't far any more IMHO.

                                     - o -

Status of the block deployer:

* Over the last few days I was working on the block deployer again:

  - the deployer can work in two modes now: transactional and
    non-transactional (the latter is the default for full
    deployments)
  - deployment takes about 2 seconds on my laptop whic is about
    25 times faster than before (~50 seconds), in non-transactional
    mode about 4
  - some refactorings to make the code more readable

* I introduced the new Maven goals
   - cocoon:deploy and
   - cocoon:deploy-war

Both are based on the Maven war plugin. A demo can be found in 
[cocoon-deployer-webapp-sample]. As you can see, deployment is based on 
cocoon-deploy.xml. This file describes which blocks you want to deploy and how 
they are configured. These blocks are deployed to the webapplication.

Before block deployment, the normal web app creation of the war plugin takes 
place which mainly consists of copying files from src/main/webapp to 
target/[finalName].

* I also cleaned up the XML schema of block.xml. I removed all types that 
contain information that is covered by Maven, except the dependencies as this 
isn't possible because of our diferent understanding of dependencies.
As the introduction of OSGi will lead to changes here again, we shouldn't invest 
too much time in optimization _for now_.


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