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)
Message-ID: <42E4ADFB.8050304@kismetsoftware.com>
Date: Mon, 25 Jul 2005 01:16:43 -0800
From: JD Daniels <jd@kismetsoftware.com>
User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] The impact of using OSGi
References: <42E4976F.30702@apache.org> <42E49A8A.2050000@odoko.co.uk>
In-Reply-To: <42E49A8A.2050000@odoko.co.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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.

JD

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
> 
>