JD Daniels wrote:
Ok, I have a question from a user perspective. I have a large, basically
company-wide build system. Each of my own projects has its own build,
which is included in a "domain" project. I have as an init task to build
cocoon, then all my little projects depending on a properties file
whether to include them. Then an awful lot of complicated xpatching to
get my final web.xml, cocoon.xconf, and sitemap.xmap.
will I be able to port (for lack of a better word) these projects into
an osgi bundle? ( they all use the CHS design ) how will the hibernate
setup and sitemaps be integrated? I have a file in each project
pipelines, logging, menus, etc that get patche din during the build. I'm
wondering if the goodness of osgi in cocoon will take care of this.
I am asking because I get the impression the osgi will be "hidden" from
me at the level I use cocoon.
Well, as far as OSGi is concerned, no, it won't manage that sort of
stuff for you. All it will do is manage components from other bundles.
However, already in trunk you have the ability to specify xconf snippets
in your sitemap, meaning you don't need to patch the core one. As far as
the web.xml file is concerned, I'd want to see us store the init-params
in a context independent manner. Where that will be, I don't yet know.
If you want to use xpatch while building your blocks, that's fine!
Personally, I want to see this patching process die, as quickly as
possible. While it works, it really isn't straight-forward. All
configuration for a block should either be in the block, or be provided
at the time you install the block. (e.g. mount point). And the core
Cocoon should require _NO_ patching at all, even when configuring really
complex apps - it should be a binary black box to many users.
Hope that helps.
Regards, Upayavira
Upayavira wrote:
Carsten Ziegeler wrote:
A lot of people have asked me during the ApacheCon (and via mail) what
the move to OSGi would mean from a user/developer perspective. So I
think it's time to discuss this a little bit further; we already did
this briefly at the hackathon, but of course we should continue this
here visibile for everyone.
(The following is how I understand/see the whole thing, please correct
me if required).
First of all, we have an RT about the goals for the next version[1]. As
noted there, the goals are independent from OSGi and the vision is to
*explore* OSGi in the next months. So actually using OSGi is not carved
in stone, but currently it looks like OSGi is the best available
alternative.
The most important goal for myself is 7): compatibility. I don't want to
rewrite each and every piece of code we've done in the past five years.
And I think it's as important to not increase the high learning curve by
introducing another "thing". Ok, from what we discussed in the last
weeks, it seems to me that we can achieve these goals.
So, what does all of this OSGi stuff mean? OSGi provides some nice
features, like isolated class loading and depedency resolution. And it's
exactly this where we want to use it.
Although OSGi is a component container by itself, we will not replace
ECM with the OSGi one. This means for a java developer nothing really
changes, you just use ECM like you did before or you use
Spring/Hivemind/Pico/whatever like you did before. Everything looks the
same.
Underneath, our own ECM implementation will use OSGi to get components
from another bundle, but this is totally transparent. The only thing you
have to do is defining your block dependencies properly. By this our own
ECM implementation will be able to lookup components from the blocks you
depend on.
For a Cocoon user (writing sitemaps, using xml and xslt) everything
should stay the same. It just works like it does today.
Now, there is one thing to consider: using OSGi means, everything is a
bundle. So whatever you develop, it must be a bundle. Currently people
are using totally different ways of developing. Some are using directly
Eclipse, others are using build systems (which copy files to the webapp
directory), others are using the compiling classloader etc. And there is
no "single right way". For me right now, this is the challenging part.
We must enable rapid development (we have it in the goals as number 3)
and I think this should not require any OSGi knowledge. I hope we get at
this point. Later on, for deployment it's ok to define the dependencies
and whatever is required.
The first time I talked with Stefano about this topic (when he visited
us in Paderborn - gosh, is this really now nearly three years ago?) we
talked about a smooth migration path: you could simply use your old
applications as they are for 2.1.x without using bundles/blocks and they
would simply still work (with all the disadvantages of course). Or you
could "migrate" and use the (new) blocks. I'm not sure anymore how we
wanted to achieve this, but I think the basic idea was to just deploy
the whole cocoon application as a big single block including everything.
On this topic, what do people expect in terms of performance? (I know it
might be a little bit early) With OSGi we add another layer/isolation,
so does this cost performance significantly?
BTW, what is the status about the dependency definition (block.xml).
What are we planning to use?
Just replying to this bit - Daniel showed me the block.xml before he
left ApacheCon. It looks pretty simple. Also, given all the other
'dependency' files we will/might need (gump.xml, manifest, maven
project files, etc) in a discussion it was suggested that we're better
of sticking with our own blocks.xml file - we can always generate
anything else we want from that.
So, AFAICS, blokc.xml stays as Stefano proposed it.
Regards, Upayavira
