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,
http://marc.theaimsgroup.com/?t=111995635000002&r=1&w=2. 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:
osgi/
bundles/
cocoon/
cocoon_servlet/
cocoon_testcase/
cocoon_webapp/
test/
jars/
jars-external/
http/
junit/
log/
framework.jar
cocoon.sh
init.xargs
...
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.
cocoon
------
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
bundles.
cocoon_webapp
-------------
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.
cocoon_servlet
--------------
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
bundle.
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 cocoon.sh for starting the framework and some
configuration files. The cocoon.sh in osgi should be integrated with
cocoon.sh 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
http://marc.theaimsgroup.com/?t=111817657600009&r=1&w=2 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
http://dev.eclipse.org/viewcvs/index.cgi/, with directory names like
"org.eclipse.osgi.services" 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
repository.
Build system
============
I have used a build system from Knopflerfish in whiteboard/osgi,
http://www.knopflerfish.org/programming.html#custom. 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 ---
WDYT?
/Daniel
