[heads-up] Block builder available

Reinhard Poetz Tue, 22 Feb 2005 00:26:55 -0800

Over the weekend I moved the block builder (whiteboard) over to trunk. I've set it up for the blocks "authentication-fw" and "session-fw".

Given that you have installed Ant (>= 1.6.0 + Xalan in its lib directory) on your system, you can change to the directories

/cocoon/blocks/supported/authentication-fw/trunk and
/cocoon/blocks/supported/session-fw/trunk

and build them (and of course you have to check them out before ;-)).

Currently following targets are available:

ant compile ............. compiles the block and all blocks
                          it depends on (incl. Cocoon core)
ant package ............. creates the JAR for the block and
                          all blocks it depends on (incl. core)
ant eclipse-project ..... creates the Eclipse files .project
                          and .classpath
ant clean ............... cleans the build directory for the
                          block and all blocks it depends on

If you have checked out Cocoon using the same structure as in our SVN, everything should work without having to set local properties - if not, you have to copy build.properties to local.build.properties where you can overwrite properties.

Yesterday I added support for project dependencies in Eclipse. If you set the property

root.block.session-fw.eclipse.dynamic=true

in the local.block.properties of the authentication-fw block, the Eclipse project of the autentication-fw block points to the Eclipse project of the session-fw.

I would be pleased if some people (especially those using *nix operating systems) could try the build targets and check whether they work as expected.

                                      - o -

Some background information, how it works (I'm going to explain it using the authentication-fw block as example):

In the root directory you find a block.xml. It is nearly the same as proposed by Stefano. It contains metadata and all dependencies on other blocks and external libraries

<block xmlns="http://apache.org/cocoon/blocks/cob/1.0";
       id="http://apache.org/cocoon/autentication-fw/1.0";>

  <name short="authentication-fw" version="1.0">
     Authentication Framework
  </name>
  <author href="http://cocoon.apache.org";>
     Cocoon Community
   </author>
  <license href="http://www.apache.org/LICENSE-2.0/";>
      Apache Software License 2.0
  </license>

  <requirements>
    <requires
      block="http://apache.org/cocoon/session-fw/1.0";
      name="session-fw"
      />
  </requirements>

  <libraries>
    <lib id="avalon-framework-api" location="core"/>
    <lib id="avalon-framework-impl" location="core"/>
    <lib id="excalibur-xmlutil" location="core"/>
    <lib id="excalibur-pool" location="core"/>
    <lib id="excalibur-sourceresolve" location="core"/>
  </libraries>

 </block>

The block builder (in its core an XSLT transformation) is invoked in build.xml:

<project default="compile" name="Build authentication-fw block">
  <property name="blockbuilder.root"
   value="../../../../trunk/tools/block-builder"/>
  <available file="${blockbuilder.root}"
   property="available.blockbuilder.root"/>
  <fail unless="available.blockbuilder.root"
   message="Property blockbuilder.root has to be set!"/>

  <xslt in="block.xml" out="build/temp/build-by-xslt.xml"
   style="${blockbuilder.root}/targets/block-descriptor2ant-script.xsl"/>

  <import file="build/temp/build-by-xslt.xml" optional="true"/>
</project>

It uses the block descriptor to generate a build script that resolves all dependencies (classpath during build, library includes for Eclipse project files). You can find this generated script in build/temp/build-by-xslt.xml.

                                      - o -

What's missing?

 - a target that builds gump.xml
   (have to learn a bit more about Gump before *I* can do it)
 - use prefixes for property names and target names to avoid naming conflicts
 - provide hooks to integrate your own targets
 - review property names
 - a target that builds the .cob files (distribution) but this
   requires that we know how a binary distribution of Cocoon 2.2 will look
   like (see next section)

                                      - o -

Currently I'm thinking a lot about how a (binary?) release of Cocoon 2.2 could look like. Carsten proposed to create the .cob files in such a way, that we only have to unpack them into a particular directory.

Well, the problem I have now is that we don't have the shielding classloader and we have to make sure that only one version of a particular jar is used in all blocks we distribute. Otherwise we get serious troubles. Any thoughts about this or a binary release in generell?

-- Reinhard P�tz Independant Consultant, Trainer & (IT)-Coach

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

                                       web(log): http://www.poetz.cc
--------------------------------------------------------------------

[heads-up] Block builder available

Reply via email to