Return-Path: 
 <dev-return-73602-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 80344 invoked from network); 22 Apr 2005 13:35:27 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 22 Apr 2005 13:35:27 -0000
Received: (qmail 89458 invoked by uid 500); 22 Apr 2005 13:35:35 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 89244 invoked by uid 500); 22 Apr 2005 13:35:33 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
List-Post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 89197 invoked by uid 99); 22 Apr 2005 13:35:32 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from essemtepe.nada.kth.se (HELO smtp.nada.kth.se) (130.237.222.115)
  by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 22 Apr 2005 06:35:31 -0700
X-Authentication-Info: The sender was authenticated as danielf using PLAIN at
 smtp.nada.kth.se 
Received: from [192.168.105.31] (localhost [127.0.0.1])
	(authenticated bits=0)
	by smtp.nada.kth.se (8.12.10/8.12.11) with ESMTP id j3MDYmon023748
	for <dev@cocoon.apache.org>; Fri, 22 Apr 2005 15:34:49 +0200 (MEST)
Message-ID: <4268FD78.10001@nada.kth.se>
Date: Fri, 22 Apr 2005 15:34:48 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Java components in blocks
References: <20050409083134.46541.qmail@minotaur.apache.org>
 <425A8A7A.1030203@nada.kth.se> <425A8EAF.7090502@apache.org>
 <255a9c1e1ee0934507a1f5447f3ef066@betaversion.org>
 <425BDF4B.8040705@apache.org>
 <3e1766b0f6774aa2f9b7a26a729043ae@betaversion.org>
 <425D0549.80401@apache.org>
 <9c28f5a45d1ec41b74503c823fa64351@betaversion.org>
 <425D5202.6050001@reverycodes.com>
 <c7fe51acb43d85bc70f9d75149201807@betaversion.org>
 <425E34D8.1070800@nada.kth.se>
 <394529d891516efa895dc2746c77cf58@betaversion.org>
 <425E8B81.3040105@apache.org> <425E8D37.7030106@dslextreme.com>
 <0f996695454c3cc853208a9a66041284@apache.org> <4260FA7A.8030001@apache.org>
 <42610B89.4060208@nada.kth.se>
 <ff2f18d8a42fe961c0daccbc0f090379@betaversion.org>
 <42628446.9000502@dslextreme.com> <42629EB8.4050500@nada.kth.se>
 <42634FE1.3030503@dslextreme.com> <4263A29B.2060804@nada.kth.se>
 <b1cf4e13caa35058211bb8e4bc16a47b@hard-bop.co! ! m>
 <4263E96B.9070504@nada.kth.se>
 <8578195f86028d32e96e33b43244403f@hard-bop.com>
In-Reply-To: <8578195f86028d32e96e33b43244403f@hard-bop.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Glen Ezkovich wrote:

> On Apr 18, 2005, at 12:07 PM, Daniel Fagerstrom wrote:
>
>> Glen Ezkovich wrote:
>>
>>> On Apr 18, 2005, at 7:05 AM, Daniel Fagerstrom wrote:
>>
<snip/>

>>> The issue here is one of deployment, where to locate the class and 
>>> which ClassLoader will load the class. It seems to me that if we 
>>> have two component deployment levels, global and sitemap, we can 
>>> pretty much accomplish the same thing as exposing or not exposing 
>>> components.
>>
>>
>> If all jars from all blocks are put in a global sitemap it just don't 
>> scale. It is hard enough to keep jars in different blocks in synch 
>> whithin the Cocoon SVN. When external developers start to develop and 
>> distribute their own blocks it will stop working.
>
>
> Agreed. Certain jars should be available cocoon wide and others not. 
> Unfortunately, this must be left up to the blocks developer to decide 
> how a particular jar gets deployed. Just as it is now.

One of the points with real blocks is to scale the community by make it 
possible for people to develop Cocoon blocks independent of ASF and the 
current set of committers and without central control. If these external 
block developers can put jars in an common unshielded area in Cocoon we 
will get the situation where they put different vesrions of the same jar 
in this common area. Sy that you have a system that depends on block A 
and block B developed by different external organizations. When you 
update Cocoon or block A or block B you suddenly realized that the last 
version have started to export a jar that it didn't exported before and 
that allready was exported from one of the other blocks in another version.

Pier allready have problems with this, that is one reason for his 
interest in this area. I have also have had problems with it from time 
to time.

So, I don't want to left it as a desicion to the blocks developers as it 
just don't scale. What Pier and I have suggested might be somewhat less 
powerfull, (but that is left to see), but it does scale. I don't want us 
to start with a contract with blocks developers that we have to restrict 
later, it is better to do it the other way around.

>> Because of that classloader isolation is needed so that a block only 
>> is exposed to the classes it actually depend on from its parent 
>> classloader. And that is complicated stuff, if you don't think so you 
>> can take a look at kernel in whiteboard.
>
> I know so. I didn't say it would be easy.

And I have no personal interest in solving that problem right now. If 
someone else has, just go ahead, as long as you don't introduce concepts 
that we allready know that they doesn't scale.

>> Things get more complicated and creates IMO unnecessary dependencies 
>> between blocks when you combine it with sitemap functionallity.
>
>
> How so? What is the alternative? Have blocks that have no component 
> dependencies? If a block depends on a component it depends on a 
> component. If a sitemap uses a component it uses a component.

Of course a block should be allowed to depend on and contain components, 
no one have said anything else. The discussion is about if a block 
should be able to expose any type of component to other blocks.

>> Because of that complexity Pier and I prefer to separate the problems.
>
>
> If you separate the problems thats fine with me, but to consider this 
> a complete solution to the total problem which is to have real blocks 
> is a mistake. When I deploy an app, I usually have a custom component 
> or two and a bunch of POJOs. If I want to package an app as a block I 
> would need to package the sitemap and associated files as a block and 
> package the jars as a bundle. A block at the very least should include 
> the bundle. As an app developer I want to have a single deployment 
> solution.  As a sys admin, I want to ensure that I don't have 30 
> copies of identical jars hanging around.

Packaging is a separate concern. Of course we want it as convenient as 
possible. Large units has the benefit that you get everything at once 
and the drawback that different complete packages might overlap and be 
redundant. But if we have automatic deployment it is probably more 
practicalt to have fine grained packaging. As long as the block you 
happen to be intersted in has a list of it dependencies the block 
deployer will take care of the work anyway.

> I understand that this is a complex problem and breaking it up into 
> smaller pieces is a wise thing to do. My basic points are that to have 
> real blocks you need a single deployment and that there are two levels 
> to deploy Java components, global and sitemap, parent sitemaps included.

I understand that you want two deployment levels. I don't want a global 
unshielded level as I'm certain that it doesn't scale.

> Initially, to have the choice of deploying Cocoon wide or sitemap wide 
> solves some basic issues. The ultimate solution is much more difficult 
> because of the multiple dependencies a block may have. It may be that 
> it is impossible to solve all possible scenarios. I don't know.

I think it would be possible to solve, but personally I don't find it 
worthwhile right now.

/Daniel