cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: [RT] Simplifying setup
Date Tue, 02 May 2006 14:00:01 GMT
Reinhard Poetz wrote:
>
> 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."
This is pretty simple. I'm tired of long  emails about theoretical 
topics.  I frankly can't understand what the heck you guys are talking 
about half the time because I never see any concrete examples in the 
emails.  I just can't give an honest to goodness answer as to whether 
this is a good thing or not without something I can wrap my arms 
around.  And looking at trunk to figure it out doesn't seem to be a 
productive way to do it as I have come to believe that trunk is never 
going to be released.  (This is my opinion - you certainly don't have to 
agree with it or like it).
>
>
> ... 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.
I also get paid to do real work.  OSGi doesn't fit in those plans.  A 
lot of other stuff in trunk does but I can't have it because a release 
of trunk isn't going to happen in 2006.  My employer won't pay me to 
work on stuff that they won't see in the next few months.  And there is 
enough stuff in 2.1 that needs fixing to keep me busy for a long time.
>
>                                      - 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.
Well, I apologize for not knowing enough about trunk to understand that 
that is how it all works now. However, I'd still like to see an example 
of how configuring via a servlet filter will make the configuration 
simpler.  Or does it just make the code simpler?

Ralph

Mime
View raw message