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 includes SPF record at
 spf.trusted-forwarder.org)
Message-ID: <44570721.6040000@apache.org>
Date: Tue, 02 May 2006 09:15:45 +0200
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Simplifying setup
References: <4455CF5C.4020300@nada.kth.se> <44562DEC.3030502@apache.org>
    <44568798.3090903@nada.kth.se>
 <74300a10330a5b0d0a8a880a.20060501154452.enycu.tbref@www.dslextreme.com>
In-Reply-To: 
 <74300a10330a5b0d0a8a880a.20060501154452.enycu.tbref@www.dslextreme.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Ralph Goers wrote:
> 
> 
> Daniel Fagerstrom said:
> 
>>Carsten Ziegeler skrev:
>>
>>>Daniel Fagerstrom wrote:
>>>
>>>><snip rt/>
>>>
>>>I'm mostly fine with your proposed changes if you think that this helps
>>>Cocoon. In the end all changes that don't require to rewrite or change
>>>our current blocks are fine for me.
>>
>>It will mean some changes for the portal block as it use the Cocoon
>>component and the same complicated setup as the the CocoonServlet.
>>Geting a component container that is setup by a servlet context listener
>>through the portlet context should work fine a simplify the portlet
>>setup as well.
> 
> 
> Please provide an example of what this would look like.  I really need to
> understand how this will simplify anything.
> 
> 
>>>But I'm remaining very sceptical wrt to a 2.2 release in general. I
>>>think one of our main goals is currently out of focus: release early,
>>>release often. This has nothing to do with this RT specifically, I just
>>>wanted to use this thread as a reminder to focus on a release :)
>>
>>My personal goal is to release a blocks based Cocoon. But if anyone want
>>to release something from trunk earlier, I'm fine with that. I just
>>don't see any activity in that direction.
> 
> 
> While true, it is unfortunate.  Switching to Maven 2 for building projects
> is a lot less scary than switching from 2.1 to an OSGi based system. That
> doesn't make it bad, but it may make the resistance to adopt it high.  I
> believe that is why it was recommended at the gettogether that the focus
> be on delivering trunk with Maven 2 by the end of the year and then
> focusing on "real blocks".   At least, that is what I remember hearing.
> 
> 
>>The important differences between 2.1 and trunk is in the cocoon-core,
>>and as long as it is as complicated as it is today, only a few people
>>understand it well enough to be able to work on it. So refactorings that
>>make the core easier to understand and less monolithic will make it
>>easier for more people to get involved, which IMO should increase the
>>chance for a release.
> 
> 
> For me, this remains to be seen.  Moving stuff from cocoon's core to OSGi
> doesn't make it any less complicated. It just makes it a different set of
> things to understand.  And unless you are getting rid of caching,
> pipelines, etc. there is still a lot of Cocoon specific stuff to
> understand.
> 
> Frankly, if trunk was completely working with Maven 2 I'd be all over it
> trying to get it into production. But since it has been in sandbox mode
> for so long, I've focused completely on 2.1 as that is what my employer
> will be using until trunk gets in a mode where I trust it.  And I don't
> see much point in learning how trunk works until it stabilizes.

Ralph,

I can't follow your argumentation anymore. How do the following statements fit 
together?

"Please provide an example of what this would look like. I really need to
understand how this will simplify anything."

and

"And I don't see much point in learning how trunk works until it stabilizes."


... so what do you want? Daniel and I spend our spare time on improving trunk 
and this takes time as nobody is paying us directly for this because we do it in 
our spare time. We have a clear goal and we communicated it dozens of times to 
the list and added all open tasks to JIRA.
If this is too slow or insufficent for your needs, you need to get involved by 
getting your hands dirty. You're complaining that things in trunk don't work as 
they should? Hey, that's your chance! I don't think that it's rocket science to 
improve things.

                                      - o -

*If* you had took the time to learn a bit more about the architecture that 
Daniel is proposing, you would learn that our work on OSGi isn't affecting the 
non-OSGi-Cocoon in any way. Look at the current way of setting up Cocoon:

"[...] The CocoonServlet creates a CoreUtil which creates a CocoonBeanFactory 
which in turn is used to get the Cocoon component, which in turn delegates most 
of it job to the SitemapLanguage which also is a component that is managed by 
the CocoonBeanFactory. A fun exercise for the interested is to try to figure out 
how and where the Cocoon component is configured and created. [...]"

Daniel's proposal was about making this process simpler and this has *nothing* 
to do with OSGi. Daniel and I believe that OSGi is the way to go but this 
doesn't necessarily mean that everything we do is OSGi-related. As we had to 
understand Cocoon internals in greater detail, we started to think more and more 
about how to simplify things, and believe me, there is room for improvment as 
the core of Cocoon has grown and got too complicated over the years.

-- 
Reinhard P�tz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

	
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de