cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject [heads up/osgi] Moving to trunk, build system and file structure
Date Wed, 06 Jul 2005 23:10:26 GMT
Moving to trunk

As I wrote yesterday, most of the core webapp samples works under OSGi. 
Now I would like to move the code to trunk and start to integrate it 
with the build system and the rest of the code ASAP, (or rather after 
the weekend). As said before, it isn't going to break anything, but it 
will introduce dependecy on OSGi jars in core. Although only "one way" 
dependencies, so if we filter away some new packages in the build 
system, one can even build the ordinary system whithout any dependencies 
on OSGi.

I'm sorry to stress you, but it is unconvenient to have the OSGi code 
separately, and I would like it to be as easy to possible to work on 
before the Blockhathon so that we can get a lot of interesting work done 
there, and not only need to work with the most basic infrastructure task.

| If you think that this integration requires a vote, or even are   |
| against it, please speak up right away. Otherwise I start to work |
| on it after the weekend.                                          |

This was the heads up part, the rest of the mail is about how to move.

Changing to Eclipse OSGi

As discussed earlier, we need to change from Knopflerfish OSGi to 
Eclipse OSGi, to be able to make the directory generator and other 
things that need directory listing to work in blocks, I have started 
to work on this and checked in the Eclispe OSGi jar and a configuration 
file. Everything that is needed loads, but the Cocoon servlet refuse to 
start and I get no error messages at all.

It might be some configuration setting that I have forgot or anything 
else, but after a couple of hours work, reading of documentation and 
reading of code I didn't get anywhere. I would really appriciate if 
someonelse could spend some work on it also. I wrote down how to start 
it and some of my observations in the end of the README file.

Anyway, I don't think that we should let this stall all other work. 
Although directory listing is important much work on implementing real 
blocks can be done even if it doesn't work yet.

Moving the bundles to trunk

Lets take a look at (some parts of) the content of whiteboard/osgi and 
see where it could go in trunk:


The directories bundles/* is the source code for the bundles. The 
compiled bundles (packaged as jars with a manifest file with OSGi 
specific fields) are placed in jars/*. Of the bundles, cocoon, 
cocoon_servlet, and cocoon_webapp are interesting to move to trunk. The 
bundle test is just a hello world bundle and cocoon_testcase was 
something that I used under development. Further thinking is needed 
before it is usefull for testing.


The cocoon bundle is a library bundle that contains cocoon.jar and all 
needed jars from lib/core. This would correspond to src/java in trunk. 
To make src/java in trunk a bundle we would just need to merge in the 
mainifest from the cocoon bundle in the src/java mainfest and create an 
extra ant task that copies in all the needed jars in the cocoon.jar 
bundle. Later we should make many of the jars that cocoon depends on own 


The cocoon_webapp bundle just contains build/webapp with the jars in 
WEB-INF/lib removed (these are handles by the OSGi bundle classloader 
instead). In trunk it would be enough to add a manifest file to 
src/webapp and have an ant task that creates a jar from src/webapp 
whithout puting any other jars into it.


The cocoon_servlet bundle does not corrrespond to anyhthing in trunk 
today. It contains OSGi specific code (an activator) that looks up the 
cocoon_webapp bundle, start a CocoonServlet (from the cocoon bundle), 
based on the cocoon_webapp bundle, and register it in an http service 

In trunk we could put this in a new src directory, e.g. src/servlet. 
Later we could move all the servlet environment specific code in Cocoon 
core to this bundle and have a corresponding cli bundle.

Other files

Most of the bundles that are needed for running Cocoon under OSGi and 
some support bundles, are downloaded automatically when one start the 
framework, (as described in the configuration file init.xargs and 
configuration/config.ini if one use Eclipse OSGi). But there are some 
bundles that are needed during compilation of our bundles: http and log 
(and junit, but that is only needed for cocoon_testcase that not is 
ready for trunk yet). These are under jars-external. Also the OSGi 
framework it self, framework.jar, is of course needed. These bundles 
could be plased in e.g. lib/osgi.

At last there is a for starting the framework and some 
configuration files. The in osgi should be integrated with in trunk and the configuration files could be placed at top 
level in trunk.

Naming conventions

Besides that we need to cretate an uniform package structure with unique 
package names for all blocks as discussed in we should also 
think a little bit about name conventions for directory names for 
bundles (blocks). Most of the directories in src will be bundles, then 
it might be more natural to rename src/java to src/cocoon.

Also I think that we at least should consider using the bundle (plugin) 
directory name convention from Eclipse, with directory names like 
"" etc. This kind of names has the advantage 
that they are unique not just in the current directory but also 
globally, which is practical when placing the generated jars in a block 

Build system

I have used a build system from Knopflerfish in whiteboard/osgi, It creates bundle 
mainfest files from ant properties and some analysis of the source code. 
It support the possibilty to have separate api and implementaion bundles 
generated from the same source. In the bundles that I wrote there are 
also some pre and post targets that copy all needed jars and unpacks 
some bundles for geting jars that are needed during compilation.

I don't think that much of this is worthwhile to move to trunk. IMO, 
there is not much gain in describing the manifest in an ant file, they 
are fairly easy to write by hand. In the begining we could do it that 
way, and later we might want to generate them from block.xml. I 
described some more things that are needed for supporting OSGi in trunk 
in the respective bundles subsections above.

                               --- o0o ---



View raw message